脆弱性体験学習ツール -...

Copyright © 2011 独立行政法人情報処理推進機構

脆弱性体験学習ツール「AppGoat」ハンズオンセミナー

独立行政法人情報処理推進機構 (IPA) 技術本部セキュリティセンター

～ウェブアプリケーション編～

本資料は、下記URLで公開しています。情報処理推進機構：情報セキュリティ：脆弱性対策 http://www.ipa.go.jp/security/vuln/index.html#seminar

http://www.ipa.go.jp/security/vuln/index.htmlhttp://www.ipa.go.jp/security/vuln/index.htmlhttp://www.ipa.go.jp/security/vuln/index.htmlhttp://www.ipa.go.jp/security/vuln/index.html

Copyright © 2011 独立行政法人情報処理推進機構 AppGoat ハンズオンセミナー 2

講義内容

ウェブサイトを狙った攻撃の実情

脆弱性体験学習

SQLインジェクション

クロスサイト・スクリプティング

クロスサイト・リクエスト・フォージェリ

IPAにおける脆弱性対策の取組み

Copyright © 2011 独立行政法人情報処理推進機構 AppGoat ハンズオンセミナー

ウェブサイトを狙った攻撃の実情（1）～組織がターゲットになる攻撃～

情報窃取を目的としたウェブサイトへのサイバー攻撃の発生

複数の有名企業を標的としたサイバー攻撃の発生。

1億件を超える個人情報が漏えいし、1ヶ月近くに渡りウェブサービスが停止。

ウェブサイトを経由し、ソフトウェアの脆弱性を狙ったサイバー攻撃。

大規模なハッカー組織による攻撃として世間を賑せた。

ウェブサイト上の個人情報やカード情報がターゲットとなる

ハッカー集団大手企業ウェブサイト

攻撃

情報の窃取

3


ウェブサイトを狙った攻撃の実情（2）～ウイルス配布サイトへ改変～

大手を含む複数企業のウェブサイトが改ざんされ、企業イメージの低下

攻撃者の狙いは、ウェブサイトではなく利用者にある

利用者をフィッシングサイトや、ウイルス感染サイトへ誘導し、情報を窃取する。

ウェブサイトが改ざんされ攻撃者の踏み台となり、結果として犯罪に加担。

利用者からのクレームや報道等により、組織のイメージ低下が避けられない。

ウェブページ改ざんには、XSSやSQLインジェクションの脆弱性が悪用されている。

ウェブサイトに多くのユーザがアクセスする為に、狙われやすい。

4


ウェブサイトを狙った攻撃の実情（3）～ミニブログサービスやSNSの利用者を狙った攻撃～

利用者が多いことに目を付けた攻撃の発生

Twitter,mixi,Facebookなどの気軽に投稿するサービスが流行

SNSサイトで「CSRF」の悪用利用者が他者を中傷するようなコメントを、意図せず投稿してしまう被害が発生

Twitterで「XSS」の悪用 Twitterの利用者に意図していない投稿を行わせたり、利用者のTwitterの表示を崩してしまう被害が発生

5


ウェブサイトへの攻撃件数の推移～iLogScanner による JVNiPedia のログ解析事例～

20件/日の攻撃を受ける月もあり、脆弱性対策を行うことが重要ディレクトリ・トラバーサルやSQLインジェクションの攻撃が顕著

解析したウェブサーバのアクセスログの期間：2010年9月～2011年8月

攻撃があったと思われる件数：平均2.8件/日、攻撃が成功した可能性の高い件数：0件

6


企業のウェブサイトを中心に複数の脆弱性が確認され、IPAへ届出られている IPAに届出られる脆弱性の8割がXSSとSQLインジェクション

企業や政府機関のウェブサイトに脆弱性が確認されている

国内では、XSSとSQLインジェクションの脆弱性を作り込みやすい傾向

ウェブサイトの脆弱性届出の傾向～XSS、SQLインジェクションの脆弱性が全体の78%～

8%

58% 5%

21%

5% 3%

企業（株式・上場）

企業（株式・非上場）

企業（その他）

団体

政府機関

地方公共団体

68% 10%

8%

5%

3%

3% 3%



ファイルの誤った公開

セッション管理の不備

HTTPSの不適切な利用

認証に関する不備

その他

7


IPAが取り扱っている脆弱性情報について、200件以上のウェブサイトが修正されていない状態である

開発工数の問題で対応できないという回答だけでなく、開発ベンダと連絡を取れずに対策ができないとの回答や、開発ベンダにメンテナンスできる人材が不在で対策できないとの回答が散見された

2年間以上対策されないウェブサイト

（出典）IPA：ソフトウェア等の脆弱性関連情報に関する届出状況 2010第4四半期

対策されていないウェブサイトの割合～脆弱性届出制度におけるウェブサイトの状況～

8


ウェブサイトへの攻撃が成功してしまう要因(一例)

① 脆弱性の放置

② 不適切なアクセス権の付与

③ システムの設定不備

・・・

脆弱性を突いた攻撃に晒される危険

攻撃者が攻撃を行いやすくなる環境の創出

不正アクセス・不正ログインの誘発

セキュリティ・脆弱性対策を学ぶには、攻撃の仕組みを理解することが重要

開発工程において脆弱性や設定不備を作り込まないことが重要

攻撃が成功してしまう背景

9


AppGoat の学習の目的

攻撃の仕組みを理解する

実機で試してみる

対策方法を理解する

攻撃の仕組みを理解し、脆弱となる作りや仕様を理解する

Step1,2で学習したことを基に、安全な実装方法を身に付ける

脆弱性により引き起こされる脅威を正しく理解する

攻撃が成功する仕組みを理解することで、脆弱性を引き起こす脅威や正しい対策方法を身に付ける

AppGoat のコンセプト

Step1

Step2

Step3

AppGoatによる学習の効果

10


教材と演習環境をセットにした学習ツール

– 教材：脆弱性対策に必要な情報を図解したもの

– 演習環境：故意に脆弱性を埋め込んだアプリケーション

学習者

学習教材

演習環境

AppGoatによる学習の効果

実践レベルのスキルの習得

知識の習得

安全なソフトウェア開発の実現

11


講義内容



SQLインジェクション脆弱性の原理解説

演習：AppGoatを用いた疑似攻撃体験

脆弱性の対策解説




12


SQLインジェクション脆弱性とは

注意が必要なウェブアプリケーション

データベースを利用しているウェブアプリケーション • コンテンツ管理システム（CMS）に脆弱性が見つかることも

脅威

データベースへの命令（SQL文）の意味を書き換えられ、データベースを不正に操作されてしまう

• 情報の改ざんや漏えい、認証の回避、OSコマンドの実行

原因

ウェブアプリケーションにおける、データベースへ

の命令（SQL文）の組み立て方に問題


リテラル SQL文中で使用される定数をリテラルと呼び、文字列型、数値型、日時型などがある

クォート(‘’) SQLにおいて、データの区切り文字として使われる特殊な意味を持つ記号。

シングルクォートを使い、文字列リテラルの範囲を示す。

コメント(--) SQLにおいて、-- 以降は、命令文ではなくコメントとして扱う。

14

SELECT name FROM employee WHERE employee_name = 'john'

SQLの基礎知識(演習を解く為のポイント)

SELECT name FROM employee WHERE employee_name = 'john'

文字列リテラルの始まり終わり

文字列型

SELECT name FROM employee WHERE age >= 25

数値型

SELECT name FROM employee -- WHERE employee_name = ‘john'

SQL文として無効となる


SQLインジェクション攻撃のイメージ図

SQL インジェクションの脆弱性がある場合、悪意あるリクエストにより、データベースの不正利用をまねく可能性があります。

SQL インジェクション

データベースへの命令文を構成する入力値を送信

データベースへ命令を送信

SQLインジェクションの脆弱性があるウェブアプリケーション

悪意のある人ウェブサイト

データベース

改ざん情報漏えい

消去

SQL文の組み立て方に問題

攻撃者がウェブアプリケーションの脆弱性を悪用して、不正なSQL文を発行し、外部からデータベースを操作する攻撃


SQL文の組み立て方に問題があると

ウェブサーバ＋ウェブアプリ

データベース

user

16

id=hanako

pass=test

例：IDとパスワードで認証するウェブアプリケーション

利用者

通常時

ID、パスワードを入力し、認証ボタンをクリックする。

ユーザの入力値をもとにSQL文を組み立て、データベースに送信する。

SELECT * FROM user WHERE

id= ' ' AND pass=' ' hanako test

SQL文の実行結果をウェブアプリに返す。

認証後の画面を表示する。


SQL文の組み立て方に問題があると


データベース

user

17

id=hanako' --

pass=123

例：IDとパスワードで認証するウェブアプリケーション

ID、パスワードを入力し、認証ボタンをクリックする。

ユーザの入力値をもとにSQL文を組み立て、データベースに送信する。

SELECT * FROM user WHERE

id= ' ' AND pass=' 123'

パスワード認証なしのSQL文が実行され、認証成功と判断される。

認証後の画面を表示する。

悪意がある人

攻撃時

・データベースが不正に操作されてしまう！！

hanako' --


通常時のSQL文 SELECT * FROM user WHERE id=' ' AND pass= ' '

攻撃時のSQL文 SELECT * FROM user WHERE id='

※SQL文中の「'hanako'」のような定数をリテラルと呼び、文字列としてのリテラルを文字列リテラルと呼ぶ。数値は数値リテラルと呼ぶ。

文字列リテラルは「'」で括り、数値リテラルは「'」で括らない。

' AND pass= ' '

18

攻撃によりSQL文の意味が書き換えられる

条件： Idがhanakoかつパスワードがtestに一致する行

条件： Idがhanakoに一致する行 -- 以降はコメント文として解釈される

hanako

hanako' --

はユーザからの入力値を表す

test

123 ' --


SQL文の意味を書き換えられてしまうと

19

データベースに蓄積された非公開情報の閲覧

データベースに蓄積された情報の改ざんによる、ウェブページの改ざん認証回避による

不正ログイン

ウェブページ改ざん

非公開情報の漏えい

不正ログイン


[演習]AppGoatを用いた疑似攻撃体験 [時間]20分（解説含む）

SQLインジェクションの下記テーマの演習を実施しましょう。「不正なログイン（文字列リテラル）」

画面上に「Congratulations!! 」と表示されると演習クリアです。

20

クリアした方は、下記テーマの演習に挑戦してみてください。「情報漏えい（数値リテラル）」


[演習]演習環境の説明

「不正なログイン（文字列リテラル）」の演習環境

登場人物

• 攻撃者

登場ウェブサイト

• SQLインジェクション脆弱性のあるオンラインバンキングサイト

21

演習中は、自身が攻撃者として行動していると考えてください。

脆弱性のあるウェブサイトに直接攻撃します。


[演習]擬似攻撃のイメージ

22

HTTP ＳＱＬ

ＳＱＬ HTTP


[演習]演習の進め方

Step1：正常時のウェブアプリの動作を確認する

手順1：「前提条件」を押下し、ユーザ認証処理に使われるSQL文を確認する。

手順2：正規のID、パスワードでログインする。

Step2：脆弱性となる箇所を見つける手順3：ログイン画面の入力フィールドに様々な値を入力して、動作を確認する。

Step3：脆弱性を突いてみる手順４：「前提条件」を参考に、認証を回避するようなSQL文を考える。

手順５：手順４のSQL文を発行するよう入力フィールドに値を入力しログインする。

ユーザからの入力値がSQL文中のどこに使われているか確認しましょう

着眼ポイント

SQL文で特別な意味を持つ文字を入力してみましょう

着眼ポイント

パスワード認証を無効とするようなSQL文を発行してみましょう

着眼ポイント

23


[演習]行き詰まった場合

問題を解くのに行き詰まった場合は、AppGoatのヒント機能を参考に演習を進めてください。

不明な点がございましたら、お気軽にお声掛けください（または挙手）。補助講師が伺います。

問題が解けた方は、認証を回避して佐藤さん（sato）としてログインしてみましょう。

24

AppGoatのヒント機能


「前提条件」ボタンを押すと、ユーザ認証処理にどのようなSQL文が使用されているか確認することができます。

[手順1] ユーザ認証処理に使われるSQL文の確認する


[手順2] 正規のID、パスワードでログインする

26

着眼ポイントに注目して、正規のID、パスワードでログインしてみましょう。ログインできたらログアウトしてください。

ユーザからの入力値がSQL文中のどこに使われているか確認しましょう

着眼ポイント


[手順3] ログイン画面の入力フィールドに様々な値を入力する

27

SQL文で特殊な意味を持つ文字を入力してみましょう

着眼ポイント

入力フィールドにシングルクォート「'」を入力し、ログインしてみましょう。

その結果、下記のようなSQL文が作成されることが推測できます。

「’」を入力したことにより、SQL文の構文エラーが発生したと推測 ⇒SQLインジェクションの脆弱性が存在する可能性

SELECT * FROM user WHERE id = ‘test‘ AND password = ‘’‘ ;


[手順4] 認証を回避するようなSQL文を考える

28

論理演算子（OR）と（'）を使って条件式を書き換える

[参考]コメント（--）を使って条件式を書き換える

SELECT * FROM user WHERE id = '1' AND password = 'A' OR 'A'='A';

SELECT * FROM user WHERE id = 'yamada' --' AND password = 'a';

SQL文として無効となる

常に成立する条件


[手順5] 攻撃により、手順4のSQL文を発行させる

29

1. 攻撃者がオンラインバンキングのログインフォームのID欄に適当な文字列、パスワード欄に「A' OR 'A'='A」の文字列を入力しログインを試みます。

2. その結果、攻撃者が山田さんとしてログインできてしまいます。

パスワード認証を無効とするようなSQL文を発行してみましょう

着眼ポイント


なぜSQL文の書き換えが可能だったのか？

DBMSにおいて特別な意味を持つ記号文字「‘」の扱いが不適切だったため。

SELECT * FROM user WHERE id='$i' AND pass='$p';

変数中の ’ が文字列リテラルの区切り文字として解釈され、SQL文の構文が書き換えられてしまった。

SQL文

SELECT * FROM user WHERE id='yamada' AND pass=‘ ';

$i=yamada $p=A' OR ‘A'=‘A の場合

SELECT * FROM user WHERE id='yamada' AND pass=‘ ';

$i=yamada $p=P@ssword の場合 P@ssword

A' OR ‘A'=‘A


[演習]AppGoatを用いた疑似攻撃体験

SQLインジェクションの下記テーマの演習を実施しましょう。「情報漏えい（数値リテラル）」


31



Step1：正常時のウェブアプリの動作を確認する

手順1：「前提条件」を押下し、口座残高照会処理に使われるSQL文を確認する。

手順2：ログイン後、口座残高照会ページを閲覧する。

Step2：脆弱性となる箇所を見つける手順3：URLパラメータに様々な値を入力して、動作を確認する。

Step3：脆弱性を突いてみる手順４：「前提条件」を参考に、他人の口座残高情報を取得するSQL文を考える。

手順５：手順４のSQL文を発行するようURLパラメータに値を入力しログインする。

URLパラメータの値がSQL文中のどこに使われているか確認しましょう

着眼ポイント

account_idに入力する値を変えて、エラーの発生有無を確認しましょう

着眼ポイント

他人の口座残高情報を取得するようなSQL文を発行してみましょう

着眼ポイント

32


「前提条件」ボタンを押すと、口座残高照会処理にどのようなSQL文が使用されているか確認することができます。

account_idは、数値リテラルを扱うことを確認します。

[手順1] 口座残高照会処理に使われるSQL文の確認する

「’」で括られていない ⇒数値リテラル

「’」で括られている ⇒文字列リテラル


[手順2] ログイン後、口座残高照会ページを閲覧する

34

口座残高照会ページを閲覧してみましょう。

URLパラメータの値がSQL文中のどこに使われているか確認しましょう

着眼ポイント

選択値がSQL文のWHERE句で使用されていると推測できる


[手順3] URLパラメータに様々な値を入力して、動作を確認する

35

account_idに入力する値を変えて、エラーの発生有無を確認しましょう

着眼ポイント

URLパラメータ（ account_id ）に test という文字列を入力し、アクセスしてみましょう。

その結果、下記のようなSQL文が作成されることが推測できます。

文字列リテラルを入力値としたことで、SQL文の構文エラーが発生したと推測 ⇒SQLインジェクションの脆弱性が存在する可能性

SELECT * FROM account WHERE id = ‘yamada‘ AND account_id = test ;


論理演算子（OR）を使って条件式を書き換える ⇒WHERE句が常に成立する条件式を作ります。

SELECT * FROM account WHERE id = 'yamada' AND account_id = 1 OR 1=1;

[手順4] 他人の口座残高情報を参照するSQL文を考える


1. オンラインバンキングにログイン済みの攻撃者が、 URLパラメータ（ account_id ）に「1 OR 1=1」の文字列を入力し、アクセスします。

2. その結果、攻撃者が他人の口座情報を取得できてしまいます。

[手順5] 攻撃により、手順４のSQL文を発行させる

37

他人の口座残高情報を取得するようなSQL文を発行してみましょう

着眼ポイント


なぜSQL文の書き換えが可能だったのか？

変数に数値が入ることを想定している箇所に、数値以外の値が含まれていたため、SQL文の意味が書きかえられた。

SELECT * FROM account WHERE id='$i' AND account_id=$ai;

変数中の文字列 OR が、SQL文の命令として解釈されてしまった

SQL文

SELECT * FROM account WHERE id='yamada' AND account_id= ;

$i=yamada $ai=1 OR 1=1 の場合

SELECT * FROM account WHERE id='yamada' AND account_id= ;

$i=yamada $ai=1 の場合 1

1 OR 1=1


SQLインジェクション脆弱性の対策

39

根本的解決「第三者によるSQL文の発行を防止する実装」 SQL文の組立ては全てプレースホルダで実装する

SQL文の組立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースAPIを用いて、SQL文のリテラルを正しく構成する

ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない

保険的対策「攻撃による影響を軽減する対策」※

詳細なエラーメッセージの抑止

データベースアカウントの権限見直し

※ 脆弱性の原因そのものを無くす対策ではない

パラメータから本来の意味を書き換えるSQL文を発行できなくする実装

POINT

攻撃者にヒントとなる情報を与えない。仮にSQL文が発行できても、操作を最小限に抑えることで影響を小さくする

POINT


静的プレースホルダを利用して、事前に用意したテンプレートに沿ったSQL文を発行

データベースエンジンで、先にSQL文の構文を確定(コンパイル)させ、後からパラメータの値を機械的な処理で割り当てる方式

SQL文の組立てをデータベースエンジンで行わせることで、意図しないSQL文の発行を防止

SELECT ＊ FROM employee WHRE id=‘■’ AND password=‘▲’;

P@ssword

SELECT ＊ FROM employee WHRE id=‘yamada’ AND password=‘P@ssword’;

値を割当てる

SQL文テンプレート

実行されるSQL文

根本的解決～静的プレースホルダを利用した対策例～

yamada

パラメータ

プレースホルダ

パラメータ


静的プレースホルダ使用時のSQL文実行の流れ

41

ウェブサイト利用者

SELECT *FROM table WHERE id = ‘●’ and passwd = ‘▲’

●=satou, ▲=a15T ●=satou, ▲=a15T

SELECT *FROM table WHERE id = ‘satou’ and passwd = ‘a15T’

実行結果

ウェブアプリケーションデータベース

静的プレースホルダ

SELECT *FROM table WHERE id = ‘●’ and passwd = ‘▲’

実行結果

●=takana, ▲=vRi5 ●=takana, ▲=vRi5

SELECT *FROM table WHERE id = ‘takana’ and passwd = ‘vRi5’

実行結果

実行結果

SQL文構文解析 (SQL文確定)

構文解析済のSQL文にパラメータを追加


【ご参考】：「安全なSQLの呼出し方」

42

http://www.ipa.go.jp/security/vuln/websecurity.html

Java + Oracle Java + MySQL

ASP.NET + Microsoft SQL Server Perl + MySQL PHP + PostgreSQL

プレースホルダの実装方法について、プログラム言語とデータベース種別毎にサンプルコードとして収録


講義内容




クロスサイト・スクリプティング脆弱性の原理解説





43


クロスサイト・スクリプティング（XSS）脆弱性とは


動的にウェブページを出力するウェブアプリケーション

脅威

出力するウェブページ（HTML）を書き換えられ、ウェブページを操作されてしまう

• 本物サイト上に偽のページが表示される、Cookieを取得される等

原因

ウェブページ出力（HTML生成）の実装に問題


タグ（< >） HTML文中で使用される記号をタグと呼ぶ。テキストは、テキスト部分に取り消し線を表示し、スクリプトは、スクリプト（JavaScript）を実行する。

クォート(' または ") HTMLにおいて、属性値の区切り文字として使われる記号。

シングルクォート（'）やダブルクォート（"）を使い、属性値の範囲を示す。

45

HTMLの基礎知識(演習を解く為のポイント)

属性値の始まり終わり

IPA

… IPA

HTMLソースウェブブラウザ



XSS攻撃のイメージ図

ウェブアプリケーション

３．スクリプトを含むウェブページを出力

悪意のある人

利用者のブラウザ悪意のある人が用意した罠ページ

１-a．罠とは知らず、悪意あるサイトの罠ページを閲覧

１-b．罠リンクを含むメールを送信

ウェブサイト

リンク

クリック！

利用者のメーラ

２．クリック等により、スクリプトを含む文字列を送信

４．利用者のブラウザ上でスクリプトが実行

Cookie漏えい

偽ページの表示

スクリプト実行

５．スクリプトの内容によってはCookie情報などが漏えい

利用者

HTML生成の実装に問題

攻撃者が罠リンクや罠サイトを用意し、利用者を罠に誘導させることで、利用者のブラウザ上でスクリプト等を実行させる攻撃



検索キーワード IPA

検索キーワード IPA


は、取り消し線を引くHTMLタグ

【IPA 】を含む検索結果 …

IPA


IPA

"" が出力され、HTMLタグとして認識されてしまう（表示が崩れる）。

【IPA】を含む検索結果


①

② ③

①’

②’ ③’

利用者

利用者

47

通常時

異常時

HTML生成の実装に問題があると


タグとして認識させられると

48

通常時のHTML

攻撃時のHTML


IPA

【】を含む検索結果 …

alert('ipa')


【



攻撃により、タグとして認識させた場合には、利用者のウェブブラウザ上で任意のスクリプトが実行され、表示の改ざんなどが可能になる

scriptタグとして解釈された


攻撃対象者を罠に誘導させる

49

攻撃対象者を罠リンクや罠サイトに誘導させることで、他人を攻撃することができてしまう。

XSS脆弱性のあるサイトA

自分自身を攻撃

攻撃者


XSS脆弱性のあるサイトA

攻撃対象者


攻撃者サイトAに期間限定情報が載ってるよ

このリンクをクリック！！

Click

他人を攻撃


スクリプトを実行されてしまうと

50

ブラウザ上に表示されている情報が偽情報に書き換えられる

気付かぬうちに悪意あるサイトへ誘導されるなりすましに

つながる情報が窃取される

悪意あるサイトへの誘導

偽情報の表示

情報窃取



クロスサイト・スクリプティングの下記テーマの演習を実施しましょう。「アンケートページの改ざん（反射型）」


51

クリアした方は、下記テーマの演習に挑戦してみてください。「掲示板に埋め込まれるスクリプト（格納型）」



「アンケートページの改ざん（反射型）」の演習環境

登場人物

• 攻撃者

利用者


• XSS脆弱性のあるアンケートサイト

• 一般的な掲示板サイト

52

掲示板サイトに罠をしかけて、アンケートサイトの脆弱性を悪用します。悪用された結果、利用者が被害を受けます。

演習中は、攻撃者としての行動と、利用者としての行動を区別するよう意識してください。


[演習]疑似攻撃のイメージ

53

XSS脆弱性のあるアンケートサイト

利用者

掲示板サイト


Click



Step1：脆弱性となる箇所を見つける手順1：アンケートページの入力フィールドに様々な値を入力して、動作を確認する。

Step2：罠リンクを設置する手順2：「ヒント」などを参考に、スクリプトを実行させるURLを考える。

手順3：罠リンクを設置するため、手順2のURLを掲示板サイトに投稿する。

Step3：罠リンク経由でアンケートサイトにアクセスする手順4：罠リンクをクリックして、スクリプトが実行されることを確認する。

HTMLにおける特別な意味を持つ文字を入力してみましょう

着眼ポイント

攻撃者の立場で、罠リンクの作成や設置に必要な手順を考えてみましょう

着眼ポイント

54

利用者の立場になり、罠リンクをクリックした後の影響を考えてみましょう

着眼ポイント



演習を円滑に進めるために

攻撃用のスクリプトを短時間で作成することは困難ですので、下記のスクリプトが実行できることをもって、演習成功と判断してください。

下記の手順で、アンケートページで入力した値がどのようにHTMLに反映されているかを確認できます。

55

アンケートページ上で右クリックし、「ソースを表示」でHTMLソースを表示する。

Internet Explorer

アンケートページ上で右クリックし、「このフレーム」⇒「フレームのソースを表示」でHTMLソースを表示する。

Firefox

document.getElementById('title').innerHTML='hack'

アンケートのタイトルを書き換えるスクリプト


[手順1] 入力フィールドに様々な値を入力する

56

アンケートサイトに存在する脆弱性の箇所を探します。複数の入力欄に「'>">」を入れて、アンケート内容に関するエラーページを表示してみましょう。

エラーページ出力（HTML生成）時において、名前欄（nameパラメータ）に入力した値がそのまま使われていることが確認できます。

HTMLソース

ウェブブラウザ上の表示


着眼ポイント


[手順2] スクリプトを実行させるURLを考える

57

アンケートサイトのXSS脆弱性を突いて、下記のスクリプトを実行させるURLを考えましょう。

1. アンケートに答えて「アンケート投稿」ボタンを押下し、アクセスするURLを確認します。

2. 脆弱性となる箇所（nameパラメータ）に、スクリプトに相当する文字列を入れます。

http://localhost/Web/Scenario102/VulSoft/enquete.php?page=2&name=

test&sex=0&old=30&company=&xss=1&trouble=1&content=

アクセスするURL

document.getElementById('title').innerHTML='hack'

アンケートのタイトルを書き換えるスクリプト

http://localhost/Web/Scenario102/VulSoft/enquete.php?page=2&name=

document.getElementById('title').innerHTML='hack'&s

ex=0&old=30&company=&xss=1&trouble=1&content=

スクリプトを実行させるURL


[手順3] 手順2のURLを掲示板サイトに投稿する

58

1. 攻撃者の立場になり、掲示板に罠のリンクを作成します。罠のリンクには、先ほど作成したスクリプトを実行させるURLを入力します。

2. 「投稿」ボタンを押下します。これで罠リンクの設置が完了しました。


[手順4] スクリプトが実行されることを確認する

59

1. 利用者の立場になり、罠のリンクをクリックし、アンケートページにアクセスします。

2. その結果、利用者のウェブブラウザ上でスクリプトが実行され、アンケートのタイトルが書きかえられることが確認できます。


なぜHTMLタグの挿入が可能だったのか？

文字列を出力する際、「文字そのもの」として出力することを想定しているにもかかわらず、その実現に必要な処理（エスケープ処理）を実装していないため。

例：「< → <」、「> → >」

「" → "」、「 & → &」など

「文字そのもの」として出力することを想定した箇所に「HTML タグ」として出力することができてしまうため、セキュリティ上の問題となる。


[演習]AppGoatを用いた疑似攻撃体験

クロスサイト・スクリプティングの下記テーマの演習を実施しましょう。「掲示板に埋め込まれるスクリプト（格納型）」


61


XSS脆弱性のタイプ

反射型攻撃には、罠サイトと脆弱性サイトを利用します。

罠サイトから脆弱性のあるサイト（ウェブアプリ）にアクセスすると、スクリプトが実行されます。

格納型攻撃には、脆弱性サイトを利用します。

脆弱性のあるサイト（ウェブアプリ）にスクリプトを埋め込めるタイプです。埋め込まれた後は、当該サイトにアクセスするたびにスクリプトが実行されます。

62



「掲示板に埋め込まれるスクリプト（格納型）」の演習環境

登場人物

• 攻撃者

• 利用者


• XSS脆弱性のある掲示板サイト

63

攻撃者は、掲示板サイトのXSS脆弱性を悪用してスクリプトを埋め込みます。その後、利用者が掲示板を閲覧した際に被害を受けます。




64

○○○○○○○○

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

○○○○○○○○

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■



Step1：脆弱性となる箇所を見つける手順1：掲示板の入力フィールドに様々な値を入力して、動作を確認する。

Step2：スクリプトを含むコメントを投稿する手順2：スクリプトを掲示板サイトに投稿する。

Step3：掲示板サイトにアクセスする手順3：掲示板サイトにアクセスして、スクリプトが実行されることを確認する。


着眼ポイント

利用者の立場になり、罠サイトにアクセスした後の影響を考えてみましょう

着眼ポイント

65

攻撃者の立場で、罠の設置に必要な手順を考えてみましょう

着眼ポイント



演習を円滑に進めるために

攻撃用のスクリプトを短時間で作成することは困難ですので、下記のスクリプトが実行できることをもって、演習成功と判断してください。

下記の手順で、掲示板に入力した値がどのようにHTMLに反映されているかを確認できます。

66

掲示板上で右クリックし、「ソースを表示」でHTMLソースを表示する。

Internet Explorer

掲示板上で右クリックし、「このフレーム」⇒「フレームのソースを表示」でHTMLソースを表示する。

Firefox

alert('Dialog by XSS')

ダイアログが表示されるスクリプト


[手順1] 入力フィールドに様々な値を入力する

67

掲示板に存在する脆弱性の箇所を探します。複数の入力欄に「test」を入れて、取り消し線が引かれているところを探しましょう。

「本文」を入力する箇所で、入力した値がそのまま使われていることが確認できます。

HTMLソース

ウェブブラウザ上の表示


着眼ポイント


[手順2] スクリプトを掲示板サイトに投稿する

68

1. 攻撃者の立場になり、掲示板にスクリプトを埋め込みます。メッセージダイアログを表示させるスクリプトを使います。

2. 「投稿」ボタンを押下します。これでスクリプトの埋め込みが完了しました。


[手順3] スクリプトが実行されることを確認する

69

1. 利用者の立場になり、掲示板サイトにアクセスします。

2. その結果、利用者のウェブブラウザ上でスクリプトが実行されます。


XSS脆弱性の対策

HTML テキストの入力を許可しない場合

HTML テキストの入力を許可する場合

全てのウェブアプリケーションに共通の対策

70

－根本的解決・HTMLにおける特別な記号文字をエスケープ処理する・URL 出力時のスキームを制限する・スクリプト要素の内容を動的に生成しない－保険的対策

・入力値チェックをする

－根本的解決・構文解析木を作成して、必要な要素のみを抽出する

－保険的対策・入力された HTML テキストから、スクリプトを除く

掲示板やブログ等のアプリ

検索や情報登録等の機能を有するアプリ

・文字コードを正しく指定する


& → & < → < " → " > → > ' → '

•HTMLにおける特別な意味を持つ「記号文字」を文字参照に置換（HTMLを許可しない場合）

•例：

入力値：alert("test");

置換後：

根本的解決～特別な意味を持つ記号のエスケープ処理～


エスケープ処理なし

エスケープ処理あり



">alert('ipa');

scriptタグとして解釈された

">

Inputタグのvalue属性の値と解釈された

根本的解決～特別な意味を持つ記号のエスケープ処理～


そもそもエスケープ処理って？

73

HTMLやSQLの構文毎に異なる、特別な意味を持つ「記号文字」（特殊記号）を"文字そのもの"として扱うために行う処理。

HTMLにおける特殊記号は、「


保険的対策～入力値チェックの位置づけ～

入力値チェックとは、利用者が入力した値の書式を確認することが主目的。

例：パスワードの長さや使用可能な文字種のチェック電話番号やメールアドレスの書式チェック

脆弱性による被害を低減する役割を果たすことがあるが、入力値チェックだけでは防げない。

74

参考：脆弱性体験学習ツールAppGoat クロスサイト・スクリプティングの「不完全な対策」


【ご参考】：安全なウェブサイトの作り方

その他の対策方法については、「安全なウェブサイトの作り方」を参照してください。

「安全なウェブサイトの作り方」には脆弱性を作り込

んでしまった失敗事例も掲載されています。

75

安全なウェブサイトの作り方改訂第5版 http://www.ipa.go.jp/security/vuln/websecurity.html


講義内容





クロスサイト・リクエスト・フォージェリ脆弱性の原理解説




76


クロスサイト・リクエスト・フォージェリ（CSRF）脆弱性とは


ログインした利用者からのみ受け付ける処理が存在するウェブアプリケーション

影響利用者が意図しない処理を実行させられてしまう

原因利用者が意図したリクエストであるかどうかを

識別する仕組みがない


CSRF攻撃のイメージ図

クリック！

ウェブサイトにCSRFの脆弱性がある場合、悪意ある人により、利用者が予期しない処理を実行させられてしまう可能性があります。

CSRF （クロスサイト・リクエスト・フォージェリ）

５．リンクのクリック等により、利用者の意図しない攻撃リクエストをウェブアプリケーションに送信

１．通常通りログイン

退会４．罠とは知らず、悪意あるサイトの罠ページ等を閲覧

３．ログインした状態を維持

２．セッションIDを発行

罠サイト

ウェブアプリケーション（ログイン用）

ウェブサイト利用者

設定変更

CSRFの脆弱性があるウェブアプリケーション

強制投稿

利用者

悪意のある人

攻撃者が罠リンクや罠サイトを用意し、ログイン済みの利用者を罠に誘導させることで、利用者の意図しない処理をさせる攻撃


利用者が意図したリクエストかどうかを識別する仕組みがないと

ウェブサーバB＋ウェブアプリ

p@3#agdM 利用者Aからパスワード変更依頼があったと判断し、パスワードを

に変更する

利用者が、パスワード変更のリクエストをウェブサーバB に送る

① ②

ログイン済みの利用者A

79

p@3#agdM

ウェブサーバB＋ウェブアプリログイン済みの利用者A

攻撃者

aaaaaa

利用者が、攻撃者が用意した罠のページを閲覧する

①

閲覧した結果、意図せずパスワード変更のリクエストをサーバB に送ってしまう

②

利用者Aからパスワード変更依頼があったと判断し、パスワードを

に変更する

③

aaaaaa

利用者が意図しない処理が実行されてしまう。上記の場合は、パスワードが aaaaaa に変更されてしまった。

攻撃者は、下記の罠ページを事前に用意する。

「パスワードを aaaaaa に変更するリクエストをウェブサーバB に送る」罠のページ

通常時

攻撃時

ログイン中

ログイン中


意図しないリクエストを送信させられると

80

意図せず、個人情報を公開するように設定してしまう

意図せず、他人に送金してしまう

意図しない内容を掲示板に投稿してしまう

不正な送金

各種設定の不正な変更

掲示板への不適切な書き込み


クロスサイト・リクエスト・フォージェリの下記テーマの演習を実施しましょう。「意図しない命令の実行」


81




「意図しない命令の実行」の演習環境

登場人物

• 攻撃者

• 利用者


• CSRF脆弱性のあるSNSサイト

• 一般的な掲示板サイト（CSRF脆弱性はない）

82


掲示板サイトに罠をしかけて、SNSサイトの脆弱性を悪用します。悪用された結果、意図せずSNSサイトの設定が変更されてしまいます。


CSRF脆弱性のある SNSサイト


Click

掲示板サイト

設定変更利用者

ログイン中



Step1：脆弱性となる箇所を見つける

手順1： SNSサイトで設定変更する際、どのようなリクエストを送っているか確認する。

Step2：罠リンクを設置する手順2：「ヒント」などを参考に、罠リンクのURLを考える。

手順3：罠リンクを設置するため、手順2のURLを掲示板サイトに投稿する。

Step3：罠リンク経由でSNSサイトにアクセスする手順4：罠リンクをクリックして、設定変更されてしまうことを確認する。

SNSサイトにおいて、ユーザ設定を変更する際のリクエストを確認しましょう

着眼ポイント

攻撃者の立場で、ユーザ設定を変更するためのリクエストを考えてみましょう

着眼ポイント

利用者の立場になり、罠リンクをクリックした後の影響を考えてみましょう

着眼ポイント

84


[手順1] どのようなリクエストを送っているか確認する

85

SNSサイトにログインして、設定変更する際にどのようなリクエストを送信しているのか確認しましょう。

SNSサイトにおいて、ユーザ設定を変更する際のリクエストを確認しましょう

着眼ポイント

http://localhost/Web/Scenario113/VulSoft/sns.php?page=4&name=yamada&ye

ar=1990&month=1&day=1&mail=yamada%40example.com&public=1

送信されるリクエスト


[手順2] 罠リンクのURLを考える

86

SNSサイトのCSRF脆弱性を突いて、「個人情報公開」の設定を「公開する」に変更するURLを考えてみましょう。

1. 前スライドで確認したリクエストから、不要なパラメータを削除します。赤字が不要なパラメータです。

2. 不要なパラメータを削除すると下記のようなリクエストになります。下記のリクエストが送信されるように罠リンクを設置します。

http://localhost/Web/Scenario113/VulSoft/sns.php?page=4&name=yamada

&year=1990&month=1&day=1&mail=yamada%40example.com&public=1

確認したリクエスト

http://localhost/Web/Scenario113/VulSoft/sns.php?page=4&public=1

罠リンクのURL


[手順3] 手順2のURLを掲示板サイトに投稿する

87

1. 攻撃者の立場になり、掲示板に罠のリンクを作成します。罠のリンクには、先ほど作成したURLを入力します。

2. 「投稿」ボタンを押下します。これで罠リンクの設置が完了しました。


[手順4] 設定変更されてしまうことを確認する

88

1. （SNSサイトにログインした）利用者の立場になり、罠のリンクをクリックし、アンケートページにアクセスします。

2. その結果、利用者のSNS設定情報が変更されてしまいます。


なぜ意図しない処理が実行されたのか？

罠ページを経由した攻撃と正規のリクエストを識別できないため

89

ログイン済みの利用者A

攻撃者

罠ページからのリクエスト A：

利用者が意図したリクエスト B:

リクエストA、Bの違いを識別することができない

CSRF脆弱性のあるウェブアプリケーションログイン中


CSRF脆弱性の対策

90

根本的解決「意図したリクエストであるかどうかを識別する実装」 POSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する

処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する

Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する

保険的対策「攻撃による影響を軽減する対策」

重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する

利用者しか知らない情報の確認や、本来の画面遷移を経ているかの確認をする

POINT

CSRF攻撃を防ぐことはできないが、利用者が異変に気付くきっかけを作ることができる。メール本文にプライバシーに関わる重要な情報を入れないように注意

POINT


根本的解決～秘密情報を利用した対策例～

秘密情報の埋め込み処理を実行する際に、秘密情報（第三者が予測困難な値）を要求し、その値が正しい場合のみに処理を実行する。

秘密情報に、セッションIDを用いる方法がある。

秘密情報は、hiddenフィールドを使用しPOSTメソッドで送る。

91


講義内容








対策の考え方や方向性の解説

「情報システムの設計・実装や運用に起因する脅威」

企画、設計・開発、運用、廃棄フェーズそれぞれにおいて脆弱性対策が必要

93

1. 企画 2. 設計 3. 実装 4. テスト 5. 運用／利用 6. 廃棄

■ 運用時対策 ■ 脆弱性対策

■ セキュアプログラミング ■ ソースコード診断

■ 脆弱性診断（ﾍﾟﾈﾄﾚｰｼｮﾝ）

攻撃

■ テスト（ﾌｧｼﾞﾝｸﾞ他）

脆弱性脅威、動向

■ 調査、動向把握、開発方針・体制整備（ﾋﾞｼﾞﾈｽｲﾝﾊﾟｸﾄ分析含む）

システム

ライフサイクル

セキュリティ対策


対策の考え方や方向性の解説

企画当該システムに想定される脅威の洗い出し

防御機能の検討と設計方針の決定

設計・開発工程セキュアプログラミングや脆弱性テストを実施し、脆弱性を除去する

運用時定常的な脆弱性対策の実施。定期的な診断の実施。

問題発生時に対応できる体制や手順の整備

廃棄時(サービス終了) 利用者へのアナウンスの実施。

サービスの確実な停止（ページ残し）

94


知っていますか？脆弱性 http://www.ipa.go.jp/security/vuln/vuln_contents/

脆弱性を分かりやすくアニメで解説。ウェブサイト運営者が知っておくべき、ウェブサイトにおける代表的な10の脆弱性(セキュリティ上の弱点)をアニメで紹介し、脅威と仕組みについて解説。

累計アクセス数

592,232件(2007/7/12～2011/3/31)

2.設計 3.実装 4.テスト 1.企画 6.廃棄

ウェブサイトにおける代表的な10の脆弱性 1. SQLインジェクション 2. クロスサイト・スクリプティング 3. CSRF(クロスサイト・リクエスト・フォージェリ) 4. パス名パラメータの未チェック/ディレクトリ・トラバーサル 5. OSコマンド・インジェクション 6. セッション管理の不備 7. HTTPヘッダ・インジェクション 8. HTTPSの不適切な利用 9. サービス運用妨害(DoS) 10. メール不正中継

5.運用／利用

96


安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html

失敗から学ぶ。 IPAに届出られた脆弱性関連情報をもとに、対策をまとめたガイド

脆弱性ごとに解説と「根本的解決」「保険的対策」を記載（9種類）

「ウェブサイトの安全性向上のための取り組み」を記載（6項目）

「失敗例」として解説と修正例について記載（6種類）

ウェブセキュリティの実装状況のチェックリストつき

ダウンロード数初版からの累計で、２５０万件突破

IPA ヒットコンテンツ！

1. 企画 2.設計 3.実装 4.テスト 5.運用／利用

6.廃棄

97


安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html


6.廃棄

網羅性巻末にはチェックリストを記載。対策の網羅性確保のために使用できる。Excel 版も公開。

設計指針として設計段階からの考慮を要する点を一望できるので、アプリケーション設計時の指針として使用可能。

発注要件として発注者がウェブアプリケーション発注時の要件として本チェックリストを使用すれば、セキュリティ上の注意点を明確化して契約できる。

巻末チェックリスト

98


ウェブサイト攻撃の検出ツール iLogScanner http://www.ipa.go.jp/security/vuln/iLogScanner/index.html

ログからウェブサイトの攻撃痕跡を

簡易に確認できます。ウェブサーバのアクセスログを解析することで、攻撃の痕跡をレポート出力します。

JavaApplet形式である為、IPAのウェブサイト上で簡易にチェックできます。

ログを解析することにより、脆弱性対策に役立てることができます。

利用者環境

Webサイト

アクセスログファイル

利用者（Webサイト管理者）

WebブラウザWebブラウザ

iLogScanner

iLogScanner提供環境

IPAのiLogScanner提供サイト

② ③

④

①

①解析対象のアクセスログファイルを用意②iLogScannerページへ接続③iLogScannerをダウンロード④アクセスログファイルを指定しiLogScannerを実行⑤解析結果表示・出力⑤

解析結果出力

1. 企画 2.設計 3.実装 5.運用／利用

6.廃棄 4.テスト

99


ウェブサイト攻撃の検出ツール iLogScanner http://www.ipa.go.jp/security/vuln/ilogscanner/index.html

100



攻撃成功の可能性

は検出されなかった。

攻撃成功は0件

それぞれの脆弱性を狙った攻撃を検出

解析レポート例

解析結果レポートで「攻撃成功の可能性」が検出された場合は、即時に原因を調査し、対策を行ってください。


ブラウザでアクセスするだけで、PCにインストールされているソフトウェア製品のバージョンが最新であるかを、簡単な操作で確認するツールです。

ソフトウェアのバージョンを確認するツール MyJVN バージョンチェッカ http://jvndb.jvn.jp/apis/myjvn/index.html



チェック対象のソフトウェア製品名一覧

最新のバージョンであるかを「○」「×」でシンプルに表示

バージョンに関する詳細情報やバージョンアップ方法を提示


Web Application Firewall （WAF）読本 http://www.ipa.go.jp/security/vuln/waf.html

攻撃による影響を低減。 WAFの動作概要、機能詳細、導入におけるポイントをまとめた手引書

各機関におけるWAFの取り組みの紹介を記載

「WAF」がどのような物であるかについて概要を記載

「WAF」の機能説明、機能の留意点を記載

「WAF」導入の際の各フェーズにおけるポイントを記載


6.廃棄

102


5分でできる！情報セキュリティポイント学習 http://www.ipa.go.jp/security/vuln/5mins_point/

1テーマ5分でセキュリティ対策を学習。重要なセキュリティポイントを気軽に学習できる時間設定(1テーマ5分)

IPAの「5分でできる！中小企業のための情報セキュリティ自社診断」(右下図およびURL参照)の診断項目を基に学習。

職場の日常の1コマを取り入れた親しみやすい学習テーマで、様々な業種・業態・従業員の構成の中小企業に対応。

2業種3職位、全105の学習テーマ


6.廃棄

http://www.ipa.go.jp/security/manager/know/sme-guide/

103


おわりに

システムライフサイクルに沿ったトータルな対応

■ 脆弱性を作り込まない ■ 脆弱性を早期に検出する ■ 脆弱性を体系的に対策する

IPAは、安心安全な情報システム、社会インフラの実現を目指します。

独立行政法人情報処理推進機構セキュリティセンター http://www.ipa.go.jp/security/index.html http://www.ipa.go.jp/security/vuln/index.html

104
http://www.ipa.go.jp/security/index.htmlhttp://www.ipa.go.jp/security/vuln/index.html

脆弱性体験学習ツール -...

Documents