経緯
なぜ今このContent-TypeヘッダのCharsetでのXSSに言及しているかというと IPAで公開されている安全なウェブサイトの作り方による資料でこの項目が今だにフォローされているからだ。
この項目が令和となった現在もフォローが必要なのか検証していきたい。
TL;DR
もう指摘基準から除外しても良いのではなかろうか
被害の恐れがある場合はIE11以前のブラウザでかつ、限定的なので。
Content-TypeヘッダのXSS??
こちらはどういうことかというかと、
ブラウザの文字コードの解釈によって実行されるクロスサイトスクリプティングの対策についての項目なのである。
通常、何も対策をしていないWebアプリケーションであれば
ユーザの入力値をサニタイズせずに画面に出力してしまう場合にXSS(クロスサイトスクリプティング)の危険性がある。
ようこそ、TESTさん!
↓
ようこそ、<script>alert(1)</script>さん!
しかし、UTF-7 という文字コードを利用した場合にもXSSの可能性が存在した。(はてなのリンクからも情報が拾えるぞ!)
ようこそ、+ADw-script+AD4-alert(1)+ADw-/script+AD4-さん!
この+ADw
から始まる文字列はUTF-7では
<script>alert(1)</script>
となる。
このHTMLをブラウザがUTF-7と解釈した場合にJSが実行される
なので、ブラウザによりUTF-7と解釈されない様に、
レスポンスのContent-TypeヘッダのCharset付与をしてXSSを防止しましょうということなのである。
今回はこのUTF-7
で実行可能なXSSの脆弱性について考えていきたい。
そもそもの経緯はIEのContent-Type無視にもあったと思う。
今でこそIEは提供元のMicrosoftでさえ、使用を推奨していないということなのでもうこの手法も大分レガシーになったのではないか。
どのパターンでXSSの脆弱性が存在するのか
セキュリティチェックリストでは以下の様に言及されている。
全てのウェブアプリケーションに共通の対策: (根本的対策として) HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行う。
では文字コード(charset)の指定を行わなかった場合にどうなるのか
実際に試してみた。
- 想定される環境
UTF-8やShift-JIS等で動作しているサイトでHTMLでcharsetを指定し忘れて
レスポンスヘッダのContent-Typeフィールドにcharsetを付与していない場合の挙動を確認する。
HTML
<html> <body> +ADw-script+AD4-alert(1)+ADw-/script+AD4- </body> </html>
レスポンスヘッダ(共通)
HTTP/1.1 200 OK Content-type: text/html
脆弱性が存在しない場合は、以下の様に記号がそのまま画面に表示されるだけになる。
(以下はChrome)
以下は、検証したブラウザとその結果である。
検証HTMLをそのまま読み込んだ場合
ブラウザ | 結果 |
---|---|
IE8 | 問題なし |
IE11 | 問題なし |
Edge | 問題なし |
Chrome | 問題なし |
Safari | 問題なし |
Firefox | 問題なし |
IE8はContent-Type無視問題
も存在するのでそのままXSSを実行してくれると思っていた。が実際にはXSSは対策されていた。
iframeで読み込んだ場合
iframeを利用して読み込んだ場合、charsetの指定がされていない時は親HTMLの文字コードが利用されるため、
このHTMLを利用して同じページを読み込んでみる。
<html> <head> <meta charset="UTF-7"> </head> <body> <iframe src="http://example.com/charset-xss.html"></iframe> </body> </html>
iframeの親HTMLのレスポンスヘッダ
HTTP/1.1 200 OK Content-type: text/html; utf-7
以下はiframeから実行した場合の画面
iframeで読み込んだ場合の結果
ブラウザ | 結果 |
---|---|
IE8 | ※親HTMLとドメインが同じならXSSが実行できる |
IE11 | ※親HTMLとドメインが同じならXSSが実行できる |
Edge | 問題なし |
Chrome | 問題なし |
Safari | 問題なし |
Firefox | 問題なし |
※親HTMLはiframeの呼び出し元となったHTML
という結果であった。
結論
検証時に用意した環境ではIEのみiframeで読み込んだHTMLとXSSの脆弱性のあるページが同じドメインであれば実行可能であった。
このiframeで読み込んだHTML
しか利用できないのであれば、悪意のある攻撃者は別ドメインしか用意することができないため
現実的にはCharsetが付与されていないことを利用したクロスサイトスクリプティングは攻撃できない
ということになる。
(同じドメイン内にcharsetが付いていないサイトとiframeを自由に指定できるというサイトは別)
所感
Edgeは既に問題の対策がされており、
IE11でさえiframeの対策がされているのであればこのContent-TypeヘッダのCharset付与のクロスサイトスクリプティング脆弱性についての項目は
現場でセキュリティ担当者が複数のサービスに対してチェックする上で負担になる代物になっているのであれば
個人的にはフォローを外しても良い様な気がする。