自サイトにクロスサイトスクリプティング攻撃してみた

うわっ!

先日、自サイトにクロスサイトスクリプティング (XSS) 脆弱性がないか色々操作してみたところ、WAF(Mod Security)、及び、Apache 設定絡みで、サイトが想定外の動作をしたので、それに関して書いてみます。

はじめに

昨日の雨と強風で手持ちの傘(骨)が歪んでしまった今日この頃、みなさんいかがお過ごしですか?

先日、色々あって自サイトに対してクロスサイトスクリプティング攻撃を仕掛けてみました。

「あ、あくまで調査・確認が目的なんだからねっ!!」

※自身の管理下にないサイトに攻撃を仕掛けると、攻撃行為と判定され、罪に問われる可能性があります。

環境

環境は以下のような感じになります。

OS Linux(Redhat系)
Apache 2.2系
WAF ModSecurity 2.8

※WAFに関しては WAF(Web Application Firewall)でWebサイトを脆弱性から守る を参照ください。

手順

クロスサイトスクリプティングに関しては クロスサイトスクリプティング脆弱性とその対策の要領 あたりを参照して下さい。

攻撃手法

リクエストパラメータに以下が含まれるような形でサイトにアクセスしてみます。

  • javascript:alert(document.cookie)
  • <script>alert(document.cookie)</script>
  • <<script>alert(document.cookie);//<</script>

エスケープ処理を適切に行う等、クロスサイトスクリプティング対策が行われていれば問題ありませんが、上記 javascript コードがそのまま (javascriptとして) 出力されてしまうような作りの場合にはクロスサイトスクリプティング脆弱性があるアプリケーションという事になります。

javascript コードがそのまま出力/実行されてしまった場合、クッキーの中身を表示するアラートダイアログが表示されます。

攻撃その1 ( ModSecurity無し )

上記 文字列たち をサイト内検索のキーワードとして入力してみます。
最初は ModSecurity (WAF) 無しの環境で実施します。
( SecRuleEngine DetectionOnly になっている環境でもよい )

XSS攻撃失敗

結果は、きちんとエスケープ処理がなされている事が確認できました。

攻撃その2 ( ModSecurityあり )

次は ModSecurity を有効にしてその1と同様の試験をしてみます。
挙動に変化はあるでしょうか?

XSS攻撃失敗

ModSecurityで攻撃が検知された場合、デフォルト設定では 403 エラーになります。
ModSecurity のログを以下に示します。
Cross-site Scripting (XSS) Attack として検知されているのが判ります。

--9642b23d-A--
[21/Apr/2015:13:30:53 +0900] VTXSfawfCp0AAEjQIcYAAAAR 118.22.169.71 55960 172.31.10.157 80
--9642b23d-B--
GET /search-result.html?queryStr=javascript%3Aalert%28document.cookie%29 HTTP/1.1
Host: www.agilegroup.co.jp
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
Referer: http://www.agilegroup.co.jp/search-result.html?queryStr=javascript
Accept-Encoding: gzip, deflate, sdch
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Cookie: _ga=GA1.3.743049700.1380691351; _gat=1; __utma=111478804.743049700.1380691351.1429583158.1429589048.878; __utmb=111478804.8.9.1429590841296; __utmc=111478804; __utmz=111478804.1429514389.876.96.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); _gali=search-box

--9642b23d-F--
HTTP/1.1 403 Forbidden
X-Frame-Options: SAMEORIGIN
Accept-Ranges: bytes
Content-Length: 2883
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

--9642b23d-H--
Message: Access denied with code 403 (phase 2). Pattern match "\\bdocument\\b\\s*\\.\\s*\\bcookie\\b" at ARGS:queryStr. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_xss_attacks.conf"] [line "127"] [id "958001"] [rev "2"] [msg "Cross-site Scripting (XSS) Attack"] [data "Matched Data: document.cookie found within ARGS:queryStr: javascript:alert(document.cookie)"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "8"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A2"] [tag "OWASP_AppSensor/IE1"] [tag "PCI/6.5.1"]
Action: Intercepted (phase 2)
Stopwatch: 1429590653236961 10389 (- - -)
Stopwatch2: 1429590653236961 10389; combined=2523, p1=162, p2=2329, p3=0, p4=0, p5=32, sr=44, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/); OWASP_CRS/2.2.8.
Server: Apache
Engine-Mode: "ENABLED"

--9642b23d-Z--

攻撃その3 ( URLパラメータ )

これまではフォームからの入力でしたが、URLのパラメータとして問題がある文字列を渡してみます。
以下のような URL に Webブラウザからアクセスする事になります。

http://www.agilegroup.co.jp/search-result.html?queryStr=<<script>alert("XSS");//<</script>

結果ですが、ModSecurityの状態 ( 有効 / 無効 ) によって、攻撃1、攻撃2と同様の結果になりました。

  • アプリは脆弱性なし ( 適切にエスケープされる)
  • ModSecurity有効の場合には、ModSecurityでXSS攻撃と判定されて403エラーになる

攻撃その4 ( URLパターン2 )

その3までは想定通りの動きです。

が、パターンを変えて以下のURLでリクエストを投げたところ

http://www.agilegroup.co.jp/?queryStr=javascript:alert(document.cookie)

amazon AMI welcome page

想定外です。

原因

ModSecurity、及び、Apache のログを確認したところ、

  • ModSecurity によって XSS 攻撃と判定されて 403 エラーになっている
  • なぜかこちらで作成している 403のエラーページが表示されていない

という状況である事が判りました。

Apache で HTTPエラーに対応するページを指定する場合には ErrorDocument ディレクティブを使います。
例えば、404 ( Page Not Found ) が発生した場合に、自作のページを表示したい場合には、Apache の設定ファイル中に以下のように設定します。

ErrorDocument 404 /error/404.html

何らかの理由で想定外のエラーページが表示されるように設定されていると思われるので、不要な ErrorDocument ディレクティブが設定されていないかチェックします。

# cd /etc/httpd
# grep ErrorDocument * -r
( 中略 )
conf/httpd.conf.org:#    ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var
conf.d/welcome.conf:#    ErrorDocument 403 /error/noindex.html

↑これか?

どうやら apache (httpd) インストール時に含まれている welcome.conf に設定されている ErrorDocument 設定が悪さをしたようです。
ModSecurity 導入前であれば何も影響しなかったと思われますが、こんなところで余計な事をしてくれました。

対策

welcome.conf の ErrorDocument 設定をコメントアウトし、Apache をリロードしたところ、想定している 403 エラーページが表示されるようになりました。

 

但し、そもそも welcome.conf 自体不要なので、最終的には welcome.conf を削除する事にしました。 → 削除だとパッケージ更新時に復活するので正しく編集する手順推奨

/etc/httpd/conf.d/

yum で Apache 2.2 系 をインストールした場合、httpd.conf には以下の設定が記述されています。

Include conf.d/*.conf

これによって、/etc/httpd/conf.d ディレクトリ以下の拡張子 .conf のファイルが設定ファイルとしてロードされます。

conf.d ディレクトリ下に、アプリケーション別・機能別の conf ファイルを記載する事で、設定を管理しやすくする事ができます。( 私も多用しています )

が、( 私含め ) インストール時に追加される conf ファイルに関しては、きちんと確認を行っていないケースは多いのではないでしょうか。

ちなみに、httpd-2.2.29 では、以下がインストールされるようです。

  • /etc/httpd/conf.d/notrace.conf
    TraceEnable off
    
    を設定している。
    Trace メソッドを無効にするため httpd.conf に上記設定をする旨解説しているページも多いですが、今は yum でインストールした場合には、notrace.conf によってデフォルトで設定される状況になっているんですね。
  • /etc/httpd/conf.d/welcome.conf

notrace.conf はセキュリティ上有用なので削除するべきではないと思いますが、welcome.conf については不要な状態になった時点で削除するなり、conf 以外の拡張子にリネームするなりしてもよいと思います。

まとめ

不要な設定ファイルは整理しよう。

※Mod Security環境構築・設定、セキュリティを考慮したWebサーバ設定等ご相談に応じます。お気軽にお問合せ下さい。