1
IPA テクニカルウォッチ
「ウェブサイトにおける脆弱性検査手法の紹介
(ソースコード検査編)」
2
目次
目次 ... 2 はじめに ... 3 注意事項 ... 3 本書の対象読者 ... 3 1. ソースコード検査の概要 ... 4 1.1. ソースコード検査とは ... 4 1.2. ソースコード検査のタイプと注意事項 ... 5 1.3. オープンソースの脆弱性検査ツールの紹介 ... 7 2. 脆弱性検査ツールの使用例 ... 8 2.1. LAPSE+ ... 8 2.2. RIPS ... 17 3. 評価・まとめ ... 22 3.1. LAPSE+の特徴 ... 22 3.2. RIPS の特徴 ... 23 4. おわりに ... 243
はじめに
2013 年は、改ざん、情報流出などのウェブサイトに関連したインシデントが多数発生す るなど、ウェブサイト運営者を悩ませた。これらインシデントの中には、ウェブアプリケ ーションの脆弱性を悪用したものも多く、開発時の脆弱性が放置されていたことが原因の1 つである。 ウェブサイトを狙った攻撃から自組織のウェブサイトを守るには、開発時からセキュア な設計、十分な脆弱性対策を行い、安全な状態でリリースすることが大切である(図 1)。脆 弱性対策を行う方法の１つとしてソースコード検査がある。ソースコード検査は、自動的 にソースコード内の問題点を洗い出すことができる手法であるため、手作業の検査に比べ 効率的に対策が行える。 本書では、ウェブサイトを構成するソフトウェア群の中で脆弱性を作りこみやすい"ウェ ブアプリケーション"にフォーカスを当て、ウェブアプリケーションの開発者が利用しやす いオープンソースのソースコード検査ツールを用いた検査について紹介している。 IPA では、ソースコード検査ツールの有効性を周知するとともに、本手法がウェブアプリ ケーションの開発工程に取り入れられることを期待している。 図1：各工程におけるセキュリティ対策注意事項
本書で紹介している検査手法は、ウェブアプリケーションの開発者がツールを利用する までの手順にフォーカスを当てており、詳細な機能については言及していない。機能の詳 細は、各ツールの提供元にて確認してください。本書の対象読者
ウェブアプリケーション開発者4
1. ソースコード検査の概要
1.1. ソースコード検査とは
ソースコード検査とは、アプリケーションの基となるソースコードに対して、脆弱性の 可能性のある特定のパターンや不適切な構文などの問題点を自動的に検出する手法である。 ソースコード検査の利点は、機械的に脆弱性検査が行われるため、人が逐次チェックする のに比べて、確実かつ迅速に対策できるところにある。一般的には、ソフトウェア開発に おいて脆弱性を作り込む「実装」や「テスト・検証」工程で採用される。 ウェブアプリケーションの開発においては、SQL インジェクションやクロスサイトスク リプティングなどの脆弱性を作り込み易い。ソースコード検査ツールを適用することで、 これらの脆弱性の可能性があるソースコード上の当該行を検知することができる。また、 ツールによっては短かすぎる関数名などコーディング規約に違反するソースコード上の問 題点を検出してくれるものもある。ソースコード全体を確認するため、通常の挙動では実 行されない処理の問題などの潜在的な問題を検出することもできる。これらの検知機能に よりセキュアなソースコードに仕上げることができる。 図2：ソースコード検査イメージ5
1.2. ソースコード検査のタイプと注意事項
本レポートでは、ソースコード検査ツールを、「ソースコード入力型」、「統合開発環境 組込み型」として分類する。2 つの利用方法は、それぞれ特徴があり、開発環境やプロジ ェクトスタイルに応じて、適宜選択してほしい。２つのタイプについて説明する。 （１）「ソースコード入力型」 「ソースコード入力型」は、ウェブサーバ等の検査環境を準備し、開発者が作成し たソースコードを検査ツールに読み込ませて検査するタイプである。検査環境を構築 する為、複数人で共有して検査することも可能である（図3）。また、本タイプはソー スコードを投入しレポートを受け取るスタイルであるため、逐次チェックする形態で はなく、モジュール単位やオブジェクト単位など、機能単位に纏まった単位のソース コードの検査を想定している。主に「実装」工程の最後や「テスト・検証」工程で利 用される。 図3：「ソースコード入力型」利用イメージ6 （２）「統合開発環境組込み型」 「統合開発環境組込み型」は、アプリケーションを開発する環境にソースコード検 査のツールをプラグインとして組み込んで検査するタイプである（図4）。開発環境に 組み込んでいるため、作成したソースコードに対して、逐次問題の有無を確認し、す ぐに修正することができる。そのため、一般的に、「実装」工程中に利用されることが 多い。なお、アプリケーション開発者の統合開発環境毎にソースコード検査ツールを 組み込まなければならないため、開発メンバの多いプロジェクトや開発メンバの入れ 替わりが多いプロジェクトでは環境準備に多少の手間がかかる。 図4：「統合開発環境組込み型」利用イメージ （３）注意事項 ソースコード検査を行う上で以下の点を注意してほしい。 ・アクセス制御・認可制御が実装されていないなどのソースコード上に存在しな い設計の不備は検出することができない。 ・検知はツール内で定義された特定のパターンに該当するソースコードの有無で 判断されるため、誤検知・未検知の有無の精査が必要である。 このことから、検査ツールの使用だけではなく、各工程での脆弱性対策を組み合わ せて実施することが大切だ。
7
1.3. オープンソースの脆弱性検査ツールの紹介
オープンソースのソースコード検査ツールは、検査のタイプや範囲が異なるツールが多 数存在する。今回は、ウェブアプリケーションでよく利用されるPHP や Java 言語を検査 できるアプリケーションを対象に紹介する。 表1：オープンソースの脆弱性検査ツール一覧 表1 から見てわかるように、ツールにより対象言語や利用の形態など様々である。 次章では、これらのツールの中からソースコード入力型ツール「RIPS」、開発環境組込み 型「LAPSE+」について、ツールの使い方や検査手順について説明する Java PHP その他 RIPS - ○ - GUI the Month of PHP Security GPLv3 ウェブアプリケーションとして動作するツール。 環境作成に他のアプリケーション（PHP、Apache等） を組み込む必要があるため、中級者向けのツー ル。 http://sourceforge.net/ projects/rips-scanner/PHP-Sat - ○ - CUI SAT.orgPHP- LGPL
Linux上でCUIで実行できるツール。 環境作成に他のアプリケーション（Nix package manager等）を組み込む必要がある点、およびCUI であるため中級者向けのツール。 http://www.program-transformation.org/PHP/ PhpSatReleases RATS (Rought Auditing Tool for Security)
- ○ ○ (Perl、 C++ 等) CUI Secure Software Inc GPLv2 Linux上でCUIで実行できるツール。 環境がLinuxであり、環境に応じて関連するパッ ケージのバージョンアップが必要となるため、中級 者向けのツール。 http://code.google.com/ p/rough-auditing-tool- for-security/downloads/list
LAPSE+ ○ - - GUI OWASP GPLv3
アプリケーションのセキュリティに関する脆弱性を検 知するプラグイン。 導入等が容易であるため、初級者向けのツール。 http://evalues.es/?q=no de/14 FindSecurityBugs ○ - - GUI Bill Pugh and David Hovemeyer LGPL Findbugsの機能を拡張しセキュリティに特化した検 査を追加するプラグイン。 導入等が容易であるため、初級者向けのツール。 http://h3xstream.github.i o/find-sec-bugs/ FindBugs ○ - - GUI Bill Pugh and David Hovemeyer LGPL WindowsやLinuxなど様々な環境で動作する。 簡易な脆弱性や危険な構文などを検査することが できる。 導入等が容易であるため、初級者向けのツール。 http://findbugs.sourcefo rge.net/ PMD ○ △ △ （C#、 Ruby 等） CUI GUI InfoEther, LLC BSD Licence WindowsやLinuxなど様々な環境で動作し、機能の 制限があるが対応言語も広い。 危険な構文などを検査することができる。 導入等が容易であるため、初級者向けのツール。 http://pmd.sourceforge. net/
Jlint ○ - - GUICUI KonstantinKnizhnik GPLv2
WindowsやLinuxなど様々な環境で動作する。 危険な構文などを検査することができる。 導入等が容易であるため、初級者向けのツール。 http://sourceforge.net/ projects/jlint/ 特徴 ダウンロードURL ソースコード 入力型 統合開発環境 組込み型 ソースコード 入力型 統合開発環境 組込み型 タイプ ツール名 対応言語 UI 開発元 ライセンス
8
2. 脆弱性検査ツールの使用例
Java 対応の LAPSE+ および PHP 対応の RIPS を使用して評価を実施した。今回は、評 価環境として、下記の演習ツールを使用した。 ・「AppGoat1」(開発言語:PHP) ・「WebGoat2」(開発言語:Java) これらの演習ツールは、学習用に脆弱性を入れ込んだソースプログラムを一部に含んで おり、クロスサイトスクリプティングやSQL インジェクションなどの脆弱性を内在してい る。
2.1. LAPSE+
(1) ツール概要 LAPSE+は、OWASP が提供するツールで、統合開発環境にプラグインとして組み込ん で動作する。開発者はコーディングを行いながら、その場で脆弱性検査と修正が行える 為、作業の手戻りが少なく効率的に作業を進めることができる。本ツールは、不正コー ド注入の危険性のあるコーディング箇所、クロスサイトスクリプティングやSQL インジ ェクションなどの主要な脆弱性について検査することができる。 (2) ツール利用手順 LAPSE+のインストールから脆弱性検査、結果出力までの一連の使用方法を以下に記 す。また組込み統合開発環境としてEclipse を利用している。なお、本来であれば、プロ グラムの実装時に利用することが一般的であるが、今回の使用方法の例では、既に作成 されたソースを開発環境に組込み検査を実施している。【環境準備】
① LAPSE+を動作させるために、統合開発環境として Eclipse および Java の環境 を準備する。
② 以下のURL から LAPSE+( LapsePlus_2.8.1.jar)をダウンロードする。 http://evalues.es/?q=node/14 1IPA が提供している体験的に脆弱性を学習できるツール。 http://www.ipa.go.jp/security/vuln/appgoat/ 2OWASP が提供しているセキュリティ演習用の学習ツール。 https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
9 ③ ダウンロードしたLAPSE+を Eclipse の plugins フォルダに保存する。
図5：Eclipse の plugins フォルダへの保存
④ Eclipse を起動し、今回の検査対象となる WebGoat のソースコードを取り込む。
10 ⑤ LAPSE+のプラグインを呼び出すために、メニューから「ウィンドウ」-「ビュ ーの表示」-「その他」の順に開く。 図7：プラグインの呼び出し１ ⑥ 表示されたダイアログからLapse+ 2.8 配下のビューを選択し、OK ボタンを押 下する。 図8：プラグインの呼び出し 2
11 ⑦ Eclipse 内にプラグインの機能が呼び出される。
図9：プラグインの呼び出し 3
【検査実行】
⑧ 表示されたビューの中から「Vulnerability Sinks」を選択し、Find sinks ボタ ンをクリックする。
図10：検査の実行
12
【結果確認】
⑨ しばらく待つと検査結果が表示される。 図11：検査結果 表2：結果項目 項目 説明 Suspicious call 脆弱性と疑われる処理 メソッド 使われているメソッド名 カテゴリー 脆弱性の種類 プロジェクト 脆弱性を含む可能性があるプロジェクト名 ファイル 脆弱性を含む可能性があるファイル名 行 脆弱性を含む可能性があるコードの行数13
【脆弱性評価】
検知された脆弱性が誤検知である可能性もあるため、検査結果を基に脆弱性の存在 を確認してみる。今回の検査結果では発見された90 件が脆弱性とみなされた。件数 が多いため、SQL インジェクションおよびクロスサイトスクリプティングの脆弱性に 対して数件確認し、誤検知の有無を確認した。 a)SQL インジェクションの脆弱性確認１(正しく検知できたケース) SqlAddData.java で検知された SQL インジェクションの脆弱性について確認する。 図12：SQL インジェクションの脆弱性確認１ 検査の結果「statement.execute(query);」の箇所が脆弱性の疑いのある箇所として 検知された。通常SQL インジェクションは、ユーザが入力したパラメータにより SQL 文が組立てられないような実装をすることで、意図しないSQL 文が外部から注入さ れるのを防止する。具体的には、プレースホルダ3等で実装される。実行されている SQL 文の箇所を確認すると「String query = "SELECT * FROM salaries WHERE userid = '" + userid + "'";」となっており、外部からのパラメータを SQL 文に使用し ており、SQL インジェクションの対策がされていないことが分かる。つまり、 「statement.execute(query);」の処理は脆弱性を誘発する可能性が高いことになり、 【正しく検知できている】ものと考えられる。 3 SQL 文の構成する際にパラメータの入力部分をあらかじめ記号に置き換えておき、SQL の実行時に実際の値を機械 的に割り当てる手法。14 b)SQL インジェクションの脆弱性確認 2(誤検知したケース) 続いてUpdateProfile.java で検知された SQL インジェクションの脆弱性について 確認する。 図13：SQL インジェクションの脆弱性確認 2 検査の結果「PreparedStatement ps = WebSession.getConnection(s).prepareStatement(query);」の箇所にて検知されていた。 さらに実行されているSQL 文を作成している箇所を確認すると「String query = "INSERT INTO employee VALUES ( " + nextId + ", ?,?,?,?,?,?,?,?,?,?,?,?,?,?)";」となっ ており、プレースホルダの処理が含まれていることが分かる。 この結果から、外部からのパラメータによりSQL 文が書き換えられる可能性は低く、 【正しく検知できていない】ものと考えられる。 c)クロスサイトスクリプティングの脆弱性確認 1(正しく検知できたケース) JSONInjection.java で検知されたクロスサイトスクリプティングの脆弱性について 確認する。
15 図14：クロスサイトスクリプティングの脆弱性確認 1 検査の結果「out.print(jsonStr);」の箇所にて検知されていた。通常クロスサイトス クリプティングは、エスケープ処理4が施されていない場合に脆弱性となりうる。出力 されている文字列を確認すると以下のようになっており、エスケープ処理が施されて いないことが分かる。
String lineSep = System.getProperty("line.separator");
String jsonStr = "{" + lineSep + "¥"From¥": ¥"Boston¥"," + lineSep + "¥"To¥": ¥"Seattle¥", " + lineSep + "¥"flights¥": [" + lineSep + "{¥"stops¥": ¥"0¥",
¥"transit¥" : ¥"N/A¥", ¥"price¥": ¥"$600¥"}," + lineSep + "{¥"stops¥": ¥"2¥", ¥"transit¥" : ¥"Newark,Chicago¥", ¥"price¥": ¥"$300¥"} " + lineSep + "]" + lineSep + "}"; つまり、「out.print(jsonStr);」の処理は脆弱性を誘発する可能性が高いことになる。 そのため、【正しく検知できている】ものと考えられる。 4 ウェブページの表示に影響のある特別な記号文字(<、>、&等)を、影響を及ぼさない HTML エンティティ(<、>、 &等)に置換する手法。
16 d)クロスサイトスクリプティングの脆弱性確認 2(正しく検知できたケース) LessonSouce.java で検知されたクロスサイトスクリプティングの脆弱性について確 認する。 図15：クロスサイトスクリプティングの脆弱性確認 2 検査の結果「out.print(s);」の箇所にて検知されていた。C)同様、出力されている 文字列を確認すると「protected void writeSource(String s, HttpServletResponse response) throws IOException」の関数の引数として入力されていた。本関数だけでは、 脆弱性の有無は判断ができないが、少なくとも関数内では、出力されている文字列に 対してエスケープ処理が施されていないことが分かる。 つまり、「out.print(s);」の処理は脆弱性を誘発する可能性が高いことになる。その ため、【正しく検知できている】ものと考えられる。 (3) 検査結果 検査結果は以下の通りである。 表3：LAPSE+の検査結果（今回のケース） 脆弱性種別 検知 誤検知 クロスサイトスクリプティング 検知 なし SQL インジェクション 検知 あり
17 (4) コメント 検査したソースコードの有効行が約28k ステップのソースであったが、検査時間は数 秒で完了し、非常に処理が速い。検査もボタン一つで実行できるため、初心者でも使い やすいツールに思える。今回評価したクロスサイトスクリプティング、SQL インジェク ションの脆弱性以外にもパストラバーサルやコマンドインジェクションなどの脆弱性も 検知していた。ウェブアプリケーションの主要な脆弱性にも対応しており、検査ツール として非常に有効なツールと言える。
2.2. RIPS
(1) ツール概要 RIPS は、ソースコード入力型のツールで、ウェブサーバ上にツールのプログラムを展 開することで、ウェブアプリケーションとして動作する。ウェブアプリケーションとし て動作するため、複数人が同時アクセスしても利用することができる。検査できる脆弱 性として、クロスサイトスクリプティングやSQL インジェクションなどウェブアプリケ ーションの主要な脆弱性やその他セキュリティ上危険なコード等がある。 (2) ツール利用手順 RIPS のインストールから脆弱性検査、レポート出力までの一連の使用方法を以下に記 す。今回はクロスサイトスクリプティングとSQL インジェクションを検査対象とした。【環境準備】
① RIPS を動作させるために、Apache および PHP をインストールする。② 以下のURL から RIPS をダウンロードし、ZIP ファイルを Apache 配下の特定 ディレクトリに展開する。
http://sourceforge.net/projects/rips-scanner/files/
18 ③ Apache を起動し、ブラウザから②で展開した RIPS のトップページにアクセス する。 図17：検査画面 ④ 検査したいフォルダ名またはファイル名を指定する。今回はソース全体を検査 するため、合わせてsubdirs にチェックを入れ、脆弱性については全対象(All) とした。なお、レポートの詳細レベルはデフォルトの値を使用した。 図18：検査対象の設定
19
【検査実行】
⑤ scan ボタンを押下し、脆弱性を検査する。対象のファイル数が多い場合は以下 の警告メッセージが表示されるが、今回はそのまま実行した。 図19：検査実行時の警告 図 20：検査実行中【結果確認】
⑥ しばらく待つと検査結果が表示される。 図21：検査結果 ⑦ 統計情報を閉じると脆弱性の詳細を確認できる。どこで脆弱性が実行され、ど のパラメータが脆弱性を引き起こす可能性があるのかを確認できる。 図22：検査結果詳細 脆弱性の実行される 可能性のある箇所。 データの流れ 脆弱性を引き起こす可能性があるパラメ ータを取り込んでいる箇所。20
【脆弱性評価】
検知された脆弱性が誤検知である可能性もあるため、検査結果を基に脆弱性の存在 を確認してみる。今回の検査結果では4 件が脆弱性として発見された。発見されたク ロスサイトスクリプティングに対して確認、誤検知の有無を確認する。なお、検査対 象のソースに含まれているSQL インジェクションについては検知できなかった。 a)クロスサイトスクリプティングの脆弱性確認１(正しく検知できたケース) smarty_internal_templatebase.php で検知されたクロスサイトスクリプティング の脆弱性について確認する。 図23：クロスサイトスクリプティング検査結果確認 1 検査の結果「echo $_output;」の箇所にて検知されていた。出力されている文字列 ($_output)を確認するとエスケープ処理が施されていなかった。 つまり、「echo $_output」の処理は脆弱性を誘発する可能性が高いことになる。そ のため、【正しく検知できている】ものと考えられる。 クロスサイトスクリプティングの脆弱性はもう1 件検出されていたが、本件とほぼ 同じ内容であるため割愛する。 エスケープ 処理なし21 (3) 検査結果 検査結果は以下の通りである。クロスサイトスクリプティングについては2 件検出し たが、全般的に検出できない箇所も多数存在した。またSQL インジェクションにおいて は検知できなかった。RIPS は、パターンファイルを有しており、ソースコード内にパタ ーンにマッチングした場合にのみ脆弱性として検出する。そのため検出できなかった脆 弱性はこのパターンにマッチしなかったものと考えられる。 表4：RIPS の検査結果（今回のケース） 脆弱性種別 検知 誤検知 クロスサイトスクリプティング 一部検知 なし SQL インジェクション 未検知 - (4) コメント 良い点として、ソースコード検査についてボタン一つで実行でき、検査が容易である ことが挙げられる。また、入力値が与えられた箇所から脆弱性の可能性のある箇所まで の一連のフローが分かるため、修正箇所等の調査を行い易い。今回、確認した脆弱性以 外にもコードインジェクション(コードエグゼキューション)の脆弱性も検知していた。機 能上コマンドインジェクション等にも対応しており、主要な脆弱性にも対応している。 使いづらい点としては、事前にApache 等のウェブサーバや PHP の環境が必要となる ため、すぐに検査を始めたい場合には向かないように思える。
22
3. 評価・まとめ
本章では、2 章で評価した結果を踏まえて、2 種のソースコード検査ツールの特徴につい て述べる。下記の表は、2 種のツールを 4 つの項目で比較したものである。 表5：各ツールの特徴比較（今回のケース） ツール名 対応言語 検知精度 操作性 検査の効率性 LAPSE+ JAVA ○ 使い易い ○ RIPS PHP △ 環境構築が煩雑 ◎ ◎非常に良い ○良い △一部難あり 各ツールに一長一短があることがわかる。対象言語や開発環境などを考慮し、適切なツ ールの選定が必要である。3.1. LAPSE+の特徴
(１)検知精度 ～簡単に脆弱性検知が可能～ 今回、クロスサイトスクリプティング、SQL インジェクションの脆弱性について検知を 試みた。今回確認した限りでは、一部誤検知があったが、どちらの脆弱性についても検知 されることを確認した。 (２)操作性 ～インストールが簡易で初期設定が不要、GUI で簡単操作～ ツールを統合開発環境用のプラグインフォルダに保存後、統合開発環境上で呼び出すだ けで、使用できる状態となる。特に、初期設定などの対応が不要で、手軽に使用すること ができる。また、GUI を通じて操作を行うため、簡易に操作することが可能である。 (３)検査の効率性 ～ボタン1 つで脆弱性を検査、使いやすいインターフェース～ LAPSE+は、ボタン 1 つで対象ソースの検査を行い、脆弱性をレポーティングしてくれ る。検査時間も早く、発見した脆弱性のソースコードの箇所に移動し、修正を行うことが できる。初級者にとって使い易いインタフェースとなっている。23
3.2. RIPS の特徴
(１)検知精度 ～簡単に脆弱性検知が可能、ただし未検知も多い～ 今回、クロスサイトスクリプティング、SQL インジェクションの脆弱性について検知を 試み、一部発見することができたが、見逃しも多かった。 危険な関数等の特定のパターンに基づき脆弱性を検知していく都合上、実装時に使用す る関数によっては検知精度にぶれがある点に注意してほしい。 (２)操作性 ～インストールが煩雑、ウェブベースのGUI で簡易操作～ ツールを動作させるためには、事前にApache および PHP をインストール・設定してお く必要があるため、検査を実際に開始するまでにやや手間がかかる。ツール起動後は、ウ ェブベースのGUI を通じて操作を行うため、簡易に操作することが可能である。 (３)検査の効率性 ～ボタン1 つで脆弱性を検査、危険なコードを含むデータの追跡で修正が容易～ RIPS は、ボタン 1 つで対象ソースの検査を行い、脆弱性をレポーティングしてくれる。 検査対象のソースコードによっては検査に数分かかるケースもある。出力されたレポート には、脆弱性の箇所に加えてどのようなフローで危険なコードを含む値が遷移してくるの かがわかるため、誤検知の判定や修正等を行う際に容易であった。GUI もウェブであり初 級者にとって使い易いインタフェースとなっている。24
4. おわりに
本書では、ソースコード検査の概要およびオープンソースのソースコード検査ツールの 評価を行い、それぞれの使い方と特徴を説明した。ソースコード検査ツールを利用するこ とでセキュリティの向上や検査のコストの低減が図れ、有効であることを示した。対象と するウェブアプリケーションの言語や開発環境などを考慮のうえ、適切なツールを選択す ることが必要となる。 開発工程にソースコード検査を導入・実施する上で、対象システムの位置づけや費用対 効果の観点から、以下の２つ： ・無償で利用できるオープンソース ・商用ツールや有償サービス の選択肢があるので、その活用を検討して欲しい。開発工程に本検査を導入することは、 製品の脆弱性対策のトータルコスト（公開後に発生した脆弱性対策含む）を低減できるも のと考える。まずオープンソースでその有効性を確認し、有償ツールの活用も視野に、開 発工程に導入することを検討して頂きたい。 ソースコード検査は非常に有効であるが、オープンソースや商用のツールでも、必ずし も網羅的に全ての脆弱性を検知できるわけではない。ウェブシステム開発者が脆弱性低減 に抜本的に対応するためには、脆弱性の具体的な知見を充分に深め、脆弱性を極力埋め込 まないセキュアなコーディング、そして埋め込まれてしまった脆弱性を検知（ソースコー ド検査等）の、トータルな対応が重要となる。更に、ウェブシステムの運用時においては、 外部からの攻撃に対応するための備えや対応が必要となる。 IPA では、これらに対応するため、ガイド5やツール6の公開やセミナーの開催などを行っ ている。特にセミナーについては、脆弱性の理解を深めるために、「AppGoat ハンズオンセ ミナー7」を定期的に開催しており、ウェブアプリケーションの脆弱性対策の基礎から学び たい方は、機会があれば是非参加して欲しい。また、教育機関での教材としてAppGoat の 活用をお薦めする。 最後に、本書がウェブアプリケーションの開発における脆弱性対策に活用され、情報サ ービスの根幹を担っているウェブシステムのセキュリティが向上されることを期待してい る。 5 脆弱性対策-普及啓発資料 http://www.ipa.go.jp/security/vuln/index.html#section20 6 各ツールの紹介-「安全なウェブサイト運営入門」、「脆弱性対策-ウェブサイト攻撃の検出ツール iLogScanner」 http://www.ipa.go.jp/security/tools/index.html#section3 7 情報セキュリティ対策 脆弱性体験学習コース「AppGoat ハンズオンセミナー」 http://www.ipa.go.jp/security/seminar/isec-semi/standard_course_guide.html#c_appgoat25 IPA テクニカルウォッチ
