IPAの「安全なウェブサイトの作り方」を読み進める第3回！
この記事は上記の文書を個人的にまとめた防備録となるので注意。
この文書の目次は以下。
1) SQL インジェクション
2) OS コマンド・インジェクション
3) パス名パラメータの未チェック/ディレクトリ・トラバーサル
4) セッション管理の不備
5) クロスサイト・スクリプティング
6) CSRF(クロスサイト・リクエスト・フォージェリ)
7) HTTP ヘッダ・インジェクション
8) メールヘッダ・インジェクション
9) アクセス制御や認可制御の欠落
前回はセッション・ハイジャック(セッション管理の不備)について学んだ。
今回は「クロスサイト・スクリプティング」について。
1.クロスサイト・スクリプティングとは
ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまいます。この問題を「クロスサイト・スクリプティングの脆弱性」と呼び、この問題を悪用した攻撃手法を、「クロスサイト・スクリプティング攻撃」と呼びます。クロスサイト・スクリプティング攻撃の影響は、ウェブサイト自体に対してではなく、そのウェブサイトのページを閲覧している利用者に及びます。
「クロスサイト・スクリプティング」とは、Webサイト上で利用者の入力をそのまま表示させる場合、悪意のあるコードをその利用者のブラウザへ送ってしまう脆弱性のこと。
発生しうる脅威は以下。
・本物サイト上に偽のページが表示される
・ブラウザが保存している Cookieを取得される（セッション・ハイジャック）
・任意の Cookieをブラウザに保存させられる（セッションIDの固定化）
注意が必要なウェブサイトは以下。プログラムから出力する処理（PHPのechoなど）をしているサイトは怪しい。
・入力内容を確認させる表示画面がある
・ご入力時の再入力を要求する画面で、前の入力内容を表示する画面がある
・検索結果の表示
・エラー表示
・コメントの反映 etc…
2.クロスサイト・スクリプティングの対策
対策は、ウェブアプリケーションの性質に合わせ、下記の 3 つに分類してる。
1) HTML テキストの入力を許可しない場合の対策
2) HTML テキストの入力を許可する場合の対策
3) 全てのウェブアプリケーションに共通の対策
1)が一般的なサイトで、2)がブログや掲示板などのこと。
1) HTML テキストの入力を許可しない場合の対策
完全に見るだけの Webサイトの場合。
ウェブページに出力する全ての要素に対して、エスケープ処理を施す
対策その1は出力する要素全てに、エスケープ処理を施す方法。
とても大変。
ウェブページを構成する要素として、ウェブページの本文やHTML タグの属性値等に相当する全て の出力要素にエスケープ処理を行います。
エスケープっていうのは、例えば「”」を「"」に変換すること。
対照の文字は「<」「>」など、HTMLで特別な効果をもたらすもの。
テキストとして出力する全てに対してエスケープ処理を行なうことが必要となる。
また、JavaScriptの document.writeメソッドなどの動的にページ内容を変更する場合にも必要。
URL を出力するときは、「http://」や「https://」で始まるURL のみを許可する
対策その2はURL出力の制限。
JavaScript対策でもあるのかな。
利用者から入力されたリンク先のURL を「<a href=”リンク先の URL”>」の形式でウェブページに出力するウェブアプリケーションは、リンク先のURL に「javascript:」 等から始まる文字列を指定された場合に、スクリプトを埋め込まれてしまう可能性があります。リンク先 のURL には「http://」や「https://」から始まる文字列のみを許可する。
hrefに 「javascript:」を指定できるのか・・・
JavaScript関係のセキュリティ知識が疎いなー
<script>…</script> 要素の内容を動的に生成しない
対策その3も JavaScript対策。
ウェブページに出力する<script>…</script>要素の内容が、外部からの入力に依存する形で動的に生成される場合、任意のスクリプトが埋め込まれてしまう可能性があります。
対処方法は、危険なスクリプトだけを排除すること・・・
だが、確実に判断することは動的に生成しないことが勧められる。
スタイルシートを任意のサイトから取り込めるようにしない
対策その4はCSSに関して。
スタイルシートには、expression() 等を利用してスクリプトを記述することができます。このため任 意のサイトに置かれたスタイルシートを取り込めるような設計をすると、生成するウェブページにスクリ プトが埋め込まれてしまう可能性があります。
expression()関数は、IEの独自拡張らしい。
絶対使わない。
2) HTML テキストの入力を許可する場合の対策
コメントを入力できるブログや掲示板などの Webサイトの場合。
入力されたHTML テキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する
ドキュメントを引用。
入力されたHTML テキストに対して構文解析を行い、「ホワイトリスト方式」で許可する要素のみを抽 出します。ただし、これには複雑なコーディングが要求され、処理に負荷がかかるといった影響もある ため、実装には十分な検討が必要です。
つまり、どういうことだってばよ・・・
正規表現の難しい版みたいな・・・？
3) 全てのウェブアプリケーションに共通の対策
全ての Webサイトに共通する項目。
HTTPレスポンスヘッダのContent-Typeフィールドに文字コード（charset）を指定する。
Content-Typeの設定。見落とさないように。
HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type: text/html; charset=UTF-8」のように、文字コード(charset)を指定できます。この指定を省略した場合、ブラウザは、 文字コードを独自の方法で推定して、推定した文字コードにしたがって画面表示を処理します。
Content-Typeにこんな理由があったとは。
省略した場合、特定の文字コードをブラウザに選択させるような文字列を埋め込んだ上（この時点で文字化け？）、その文字コードで解釈した場合にスクリプトのタグとなるような文字列を埋め込む可能性があると。
保険的な対策は各自で見て。
・入力値の内容チェックを行う
・入力されたHTML テキストから、スクリプトに該当する文字列を排除する
・Cookie情報の漏えい対策として、発行する Cookieに HttpOnly属性を加え、TRACEメソッドを無効化する
詳しくは徳丸さんの記事も参照。
安全なウェブサイトの作り方を読み終わったら徳丸さんの本を読む！
→ 読んだ。簡単な感想など。
コメント