検索
連載

mod_securityのXSS対策ルールを作成する：Webアプリケーションに潜むセキュリティホール（12）（1/2 ページ）

[中村隆之，三井物産セキュアディレクション] PC用表示 関連情報
Share
Tweet
LINE
Hatena

※ご注意

他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。

本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。

また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。


　前回は一般的なWebアプリケーションファイアウォール（WAF）に関する説明と、mod_securityのインストールおよび簡単な使い方について説明した。今回はもう少し実用的な設定を考えてみることにする。本稿で説明するmod_securityのルールは、一般的なアプリケーション向けのものである。簡単で、かつ効果が大きくなるような設定を目指している。

ポジティブモデルかネガティブモデルか

　前回説明した、WAFの防御方針であるが、ポジティブモデルとネガティブモデルのどちらがよいだろうか。mod_securityでポジティブモデルの考え方を使うには、Webアプリケーションが扱うパラメータの種類をすべて理解しなければならない。パラメータの種類をすべて把握し、フォーマットを正規表現で指定できるのであれば、わざわざWAFでこの処理を行う必要などなく、Webアプリケーション側で行えばいいことになる。この結果、自動でルールを設定できないmod_securityにおいては、不正な文字を規制する、ネガティブモデルを使うことになる。

　ネガティブモデルでは、不正文字を指定することによって攻撃を防ぐ。この設定方法では、不正文字としてどのような文字を指定すればよいかがポイントとなる。また、基本的にすべてのリクエストが対象となるため、攻撃ではないリクエストがルールにマッチしないようにしなければならない。

　ポジティブモデルでは、あるリクエストのあるパラメータの正しいフォーマットが分かっているので、不正文字1文字（シングルクオーテーションやパイプなど）に対してもマッチさせることができる。だが、ネガティブモデルでは基本的にすべてのパラメータに共通のルールセットとなるため、例えばダブルクオートが不正文字に当たるかどうかは、どのパラメータかに完全に依存する。そのため、ネガティブモデルでは、攻撃が成功するために必要な文字列にマッチさせる方法を取るのがよいだろう。

クロスサイトスクリプティング攻撃を検知するには

　クロスサイトスクリプティングを防御するルールセットを考えてみよう。防御するには、攻撃方法を知らなければならない。以下に、代表的な攻撃パターンを挙げる。クロスサイトスクリプティングの詳細は以前の特集などを参照していただきたい。

  1. ">"><script src=...>...</script>
  2. "><style type="text/javascript">...</style>
  3. javascript: ...
  4. vbscript: ...
  5. about:<script>...
  6. expression( ...
  7. <link rel="stylesheet" href="http://xxxx/bad.css=">
  8. "><img src="" onError="...;">
  9. a href="&{...};"
  10. "><body onload= ...
  11. そのほかのイベントハンドラの使用
  12. document.cookie
  13. %0d%0a%0d%0a<script src="...">...
  14. ActiveXObject("Microsoft.XMLHTTP")
代表的な攻撃パターン

【関連記事】
▼クロスサイトスクリプティング脆弱性とは？
▼XSS脆弱性により起こる被害とその対策
▼XSSを防ぐために不可欠なサニタイジング（無害化）

　なお、スクリプトをINPUTタグの外に出すための方法として「'>」と「">」があるが、上記のリストでは、これらの区別は行っていない。また、14はXST（Cross Site Tracing）で使われるパターンであるが、XSTはクロスサイトスクリプティングの延長線上にある攻撃手法であるため、ここに含めることにする。

　mod_securityでは、前述した1〜14の攻撃パターンのうち、攻撃と認識できる部分についてマッチさせる。危険なパターンとして使用する部分とその部分を使用する理由を以下に示す。

1．<script ...>

　基本的に後付けでJavaScriptは埋め込まないので、<script>タグは不正として扱ってよい。

2．<style ...>

　スタイルシートをユーザーが指定することはない。<style>タグを使うと、スクリプトを動作させることができるため危険である。

3．javascript:

　疑似プロトコルを使うことはない。

4．vbscript:

　3と同じ。疑似プロトコルを使うことはない。

5．about:

　3と同じ。疑似プロトコルを使うことはない。

6．expression(

　スタイルシートの中でスクリプトを呼び出せるため危険である。

7．<link ...>

　ユーザーがタグを入力することはない。<link>タグを使うと、スクリプトを動作させることができるため危険である。

8．（11に含める）

9．&{...};

　スクリプトを呼び出すためだけの記述方法である。

10．<body ... onload=

　<body>タグ、およびonloadイベントハンドラは、ページ改ざんで使われる。ユーザーが<body>タグを入力することは異常である。

11．onMouseOver、onClickなどすべて

　イベントハンドラはスクリプトを動作させることができるため危険である。

12．document.cookie

　スクリプトからCookieへのアクセスができるため危険である。

13．%0dと%0a

　ユーザー入力がCookieとして返される仕様の場合に危険な文字となる。ただし、アプリケーションの中にTEXTAREAを含むフォームでは改行コードが含まれる場合があるので、ほかの危険な文字列と同じように改行コードを危険な文字列として指定することはできない。改行コード自体は、クロスサイトスクリプティング攻撃だけでなく、SPAMの踏み台（第8回を参照）などでも使用するので、全く指定しないわけにはいかない。このため次のどちらかの方法を取る。

  • TEXTAREAを受け取るパラメータ以外で改行コードを禁止する。
  • JavaScriptでTEXTAREA内の改行コードをほかの文字に変換してから送信させることで、正常入力で改行コードが含まれることがないようにする。この場合、アプリケーションの仕様変更が必要となる。また、ユーザー側でJavaScriptが必須となる。

14．Microsoft.XMLHTTP

　XST攻撃で必ず必要となるオブジェクトであるため、この文字列を禁止すれば、XST攻撃ができなくなる。

　それでは、これらの危険な文字列をmod_securityのルールとして記述していくことにしよう。

←「第11回」へ


Copyright © ITmedia, Inc. All Rights Reserved.

　　　　　　 | 次のページへ
ページトップに戻る