【連載】
セキュアなWebサイトを運営するための
Webアプリケーションに潜むセキュリティホール

第12回 mod_securityのXSS対策ルールを作成する

中村隆之
三井物産セキュアディレクション
2004/9/16

※ご注意

他社および他組織の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>タグを入力することはない。<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回」へ
1/2

Index
mod_securityのXSS対策ルールを作成する
Page1
ポジティブモデルかネガティブモデルか
クロスサイトスクリプティング攻撃を検知するには
　 Page2
クロスサイトスクリプティング用のルール
Snortのルールを流用する

Webアプリケーションに潜むセキュリティホール バックナンバー


Profile
中村隆之（なかむらたかゆき）
三井物産セキュアディレクション株式会社勤務。 セキュリティコンサルタントとして主にWebアプリケーションのセキュリティ検査に従事しており、大手ポータルサイト、オンラインバンキングなどの数多くの検査実績を持つ。また、セキュアネットワーク及び暗号関連の研究に携わり、大手製造、官公庁、金融機関へのセキュリティシステム導入など数多くの実績を持つ。

三井物産セキュアディレクション株式会社
主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サー ビスも実施中。

関連記事
特集：クロスサイトスクリプティング対策の基本
連載：不正侵入の手口と対策
連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために

Security&Trust記事一覧

TechTargetジャパン

Security&Trust フォーラム 新着記事

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード

＠IT 新着記事

キャリアアップ

- PR -
＠IT Sepcial
→ ＠IT Special ヘ

イベントカレンダー

PickUpイベント

- PR -
もっと見る
- PR -

お勧め求人情報

ホワイトペーパー（TechTargetジャパン）

＠IT Sepcial
→ ＠IT Special ヘ
ソリューションFLASH