スクリプトを埋め込まれやすいウェブアプリケーションについて

ｘｘｘｘｘｘｘｘｘｘｘｘ xxxxxxxxxx

登録

ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ

4.2 スクリプトを埋め込まれやすい

•

入力値に細工した文字列を指定

•

指定されたスクリプトがブラウザ上で実行される

•

スクリプトの内容は攻撃者次第

ｘｘｘｘｘｘｘｘｘｘｘｘ

■スクリプトを埋め込まれやすい

ウェブアプリケーションについて（続き）

xxxxxxxxxx

登録

ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ

><script>alert(“test”);</script>

xxxxxxxxxx

4.3

改善前のクロスサイト・スクリプティング対策

• 危険な文字の削除

– script

など、危険と判断した文字にマッチングしたら削除

• 入力値チェック

–

ブラウザ側での入力制限

–

念のため、ウェブアプリケーション側でも実施

例：「 script 」を削除

■「危険な文字の削除」には漏れが・・

入力値：<script>alert("test");</script>

削除後：

入力値：<script>alert("test");</script>

削除後：< >alert("test");</ ><>alert("test");</>

入力値：<sscriptcript>alert("test");</sscriptcript>

削除後：<s cript>alert("test");</s cript><script>alert("test");</script>

script script

• 削除処理の結果、スクリプト生成

• 入力値によっては対応できない場合がある

■どうすればよかったのか？

& → &

" → "

< → <

> → >

• 「削除」ではなく「置換」

• 「記号文字」を置換

（

HTML

を許可しない場合）

• 例：

入力値：<script>alert("test");</script>

•

「削除」ではなく「置換」

•

「記号文字」を置換できない場合でも同様例：

■どうすればよかったのか？（続き）

「

script

」を「

xscript

」に置換

入力値：<script>alert("test");</script>

置換後：<xscript>alert("test");</xscript>

入力値：<sscriptcript>alert("test");</sscriptcript>

置換後：<sxscriptcript>alert("test");</sxscriptcript>

ただし、ブラックリスト方式は漏れが起こりやすい

例： ScRiPt, javas	cript

ブラウザ側で入力制限

ウェブアプリケーション側で入力値チェック

ウェブアプリケーション

入力値チェック

入力値処理

出力処理

ｘｘｘｘｘｘｘｘｘｘｘｘ xxxxxxxxxx

登録

ブラウザ

■入力値チェックで安全は確保できるか ?

処理済み入力値

氏名：情報太郎

処理済み入力値

氏名:script 入力値

処理氏＋名

入力値処理

氏:情報名:太郎

入力値

氏:scr 名:ipt

•

チェック通過後の処理によって危険な文字が生成

•

チェックに漏れが生じている可能性も

入力値チェック

出力処理

「script」は許可しない！

チェック通過

入力値スクリプト

実行

■入力値チェックが機能しない例

チェック通過

• チェックのタイミングを意識する

–

出力時の値に注目

入力値チェック

入力値処理

出力

入力値入力値処理済み処理

入力値

出力対象に注目！

■どうすればよかったのか？

① 「排除」ではなく「置換（エスケープ）」

② 置換処理は「出力」対象の値に実施

参考：

「安全なウェブサイトの作り方」 1.5 クロスサイト・スクリプティング http://www.ipa.go.jp/security/vuln/websecurity.html

4.4

改善後のクロスサイト・スクリプティング対策

付録

ウェブアプリケーションの

安全性向上のためのポイント

■脆弱性はこうして生まれる

• 誤った認識（セキュリティ＝パッチで OK ）

• 初心者プログラマによるコーディング

• 無料 CGI を安易に設置

• 見落とし、コーディングミス

• 新しい脆弱性、攻撃手法の発見

ウェブアプリケーションの安全性は

開発者、運営者が「積極的に」確保すべき

■安全性向上のためのポイント

• 「削除」と「置換」

• 「入力値チェック」と「出力値チェック」

• 「危険な実装」

• 「ホワイトリスト」と「ブラックリスト」

• 「本質的解決」と「保険的対策」

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

件名コメント

送信

<input type="hidden" name="to" value="foo@

example.com">

</form>

■危険な実装とは

・・・攻撃が成立する可能性が高い実装

例：メールフォーム

■ hidden の使い方に注意

• 値の改ざんは極めて容易

– [email protected]

→

[email protected]

• 攻撃者の行動

–

宛先を改ざんし、迷惑メールを送信

–

さらに他のメールヘッダも改ざん（※）

■危険な実装の例

例： hidden に SQL 文を指定

• 値の改ざん＝任意の SQL 文を指定可能

– "SELECT...FROM list WHERE id=1"

↓

– "DROP TABLE list"

<input type="hidden" name="sql" value=

"SELECT...FROM list WHERE id=1">

■危険な実装は避けましょう

• hidden を利用した重要項目の送信

–

論外

–

攻撃の糸口をわざわざ用意しているのと同じ

–

修正には設計、仕様からの見直しが必要

重要な情報はウェブアプリケーション側で

■「ブラックリスト」と「ホワイトリスト」

パターンマッチングによるフィルタ方式の違い

• ブラックリスト

–

原則「許可」

–

リストにマッチした場合はブロック

• ホワイトリスト

–

原則「不許可」

–

リストにマッチした場合は通過

■フィルタの具体例

例：$filename に入力された値をフィルタ

file_1.txt script

scr ipt

許可不許可不許可不許可不許可許可

不許可許可許可不許可

入力値ホワイトリスト

file̲*.txt ブラックリスト

script

■「ホワイトリスト」のメリット・デメリット

• メリット

–

ブラックリスト方式よりも安全性が高い

–

未知の攻撃にも対応可能

• デメリット

–

厳格で柔軟性がない

–

対象によっては洗い出しが困難

–

複雑なコーディングが要求される場合も

■「ブラックリスト」のメリット・デメリット

• メリット

–

対象の洗い出し、コーディングが容易

• デメリット

–

漏れやすり抜けが発生しやすい

–

未知の攻撃には対応不可

ホワイトリストの実装が理想だが、困難な場合もある。

■「根本的解決」と「保険的対策」

• 根本的解決：

–

脆弱性の原因を作らない実装

–

攻撃手法を問わず有効

• 保険的対策：

–

攻撃による影響を低減する対策

–

脆弱性そのものは無くならない

–

多重防御の観点

詳細は「安全なウェブサイトの作り方」参照

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

■具体例： SQL インジェクション

• エスケープ処理の実施

–

バインドメカニズム

–

関数、置換演算子の利用

• エラーメッセージの非表示

根本的解決

保険的解決

■具体例：クロスサイト・スクリプティング

• 出力値のエスケープ処理

–

記号文字を置換

• ホワイトリスト方式によるフィルタ

• ブラックリスト方式によるフィルタ

–

入力値のチェック

根本的解決

保険的解決

■まとめ：ウェブアプリケーションの

安全性向上のためのポイント

• 実施する対策の効果や性質を正しく理解する

• 安全なプログラミング知識を身に付ける

参考サイト：

安全なウェブサイトの作り方

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

セキュア・プログラミング講座

http://www.ipa.go.jp/security/awareness/vendor/programming/

■情報システムの脆弱性対策への取り組み

〜情報セキュリティ早期警戒パートナーシップ〜

製品開発者

脆弱性関連情報届出

対応状況の集約，公表日の調整等報告された

脆弱性関連情報の内容の確認

システム導入支援者

対応状況等公表

【受付機関【受付機関】】

セキュリティ対策推進協議会等

発見者

IPA

公表日の決定，

海外の調整機関との連携等

JPCERT /CC

【調整機関【調整機関】】脆弱性関連

情報通知

ユーザ

政府企業個人

ソフトウエア製品の脆弱性ウェブサイトの脆弱性

脆弱性関連情報届出

ウェブサイト

脆弱性関連情報通知運営者

検証，対策実施

個人情報漏えい時は事実関

係を公表

①製品開発者及びウェブサイト運営者による脆弱性対策を促進

②不用意な脆弱性関連情報の公表や脆弱性の放置を抑制

【期待効果】

IPA, JPCERT/CC

対策情報ポータル

（JVN）

■ＩＰＡ新着情報メール配信

情報処理推進機構ホームページの新着情報を電子メールでご案内しています。

■ ソフトウェア開発、調査等に関する公募情報

■ セキュリティ対策情報

■ 入札情報

■ イベント・セミナー情報

■ 情報処理技術者試験情報

ウイルス対策不正アクセス対策

NEWS

緊急対策情報

対策実践情報暗号技術

セキュリティ評価・認証

脆弱性情報

・ウイルス対策

・不正アクセス対策

・脆弱性対策

【読者層別】

・情報シス責任者向け情報セキュリティ読本

・システム管理者向け

・エンドユーザー向け

・ホームユーザ向け

・SOHO向け

・ネットワーク

サービス事業者向け

URL http://www.ipa.go.jp/security/

IPAセキュリティセンターのホームページ

スクリプトを埋め込まれやすい ウェブアプリケーションについて

4.2 スクリプトを埋め込まれやすい

•

•

•

■スクリプトを埋め込まれやすい

ウェブアプリケーションについて（続き）

4.3

• 危険な文字の削除

– script

• 入力値チェック

–

–

例： 「 script 」 を削除

■「危険な文字の削除」には漏れが・・

• 削除処理の結果、スクリプト生成

• 入力値によっては対応できない場合がある

■どうすればよかったのか？

• 「削除」ではなく「置換」

• 「記号文字」を置換

HTML

• 例：

•

•

■どうすればよかったのか？（続き）

script

xscript

■入力値チェックで安全は確保できるか ?

•

•

■入力値チェックが機能しない例

• チェックのタイミングを意識する

–

■どうすればよかったのか？

① 「排除」 ではなく 「置換（エスケープ）」

② 置換処理は 「出力」 対象の値に実施

4.4

付録

ウェブアプリケーションの

安全性向上のためのポイント

■脆弱性はこうして生まれる

• 誤った認識（セキュリティ ＝ パッチで OK ）

• 初心者プログラマによるコーディング

• 無料 CGI を安易に設置

• 見落とし、コーディングミス

• 新しい脆弱性、攻撃手法の発見

■安全性向上のためのポイント

• 「削除」 と 「置換」

• 「入力値チェック」 と 「出力値チェック」

• 「危険な実装」

• 「ホワイトリスト」 と 「ブラックリスト」

• 「本質的解決」 と 「保険的対策」

■危険な実装とは

・・・攻撃が成立する可能性が高い実装

例：メールフォーム

■ hidden の使い方に注意

• 値の改ざんは極めて容易

– [email protected]

[email protected]

• 攻撃者の行動

–

–

■危険な実装の例

例： hidden に SQL 文を指定

• 値の改ざん ＝ 任意の SQL 文を指定可能

– "SELECT...FROM list WHERE id=1"

– "DROP TABLE list"

■危険な実装は避けましょう

• hidden を利用した重要項目の送信

–

–

–

■「ブラックリスト」 と 「ホワイトリスト」

パターンマッチングによるフィルタ方式の違い

• ブラックリスト

–

–

• ホワイトリスト

–

–

例：「 script 」を削除

① 「排除」ではなく「置換（エスケープ）」

② 置換処理は「出力」対象の値に実施

• 誤った認識（セキュリティ＝パッチで OK ）

• 「削除」と「置換」

• 「入力値チェック」と「出力値チェック」

• 「ホワイトリスト」と「ブラックリスト」

• 「本質的解決」と「保険的対策」

• 値の改ざん＝任意の SQL 文を指定可能

■「ブラックリスト」と「ホワイトリスト」

■「ホワイトリスト」のメリット・デメリット

■「ブラックリスト」のメリット・デメリット

■「根本的解決」と「保険的対策」

■ＩＰＡ新着情報メール配信