僕と技術とセキュリティ

セキュリティエンジニアの備忘録

令和になった今、Content-TypeヘッダのCharset付与によるクロスサイトスクリプティングについて考えてみる

経緯

なぜ今この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)

Chrome_no_xss
Chromeで検証した画面

以下は、検証したブラウザとその結果である。

検証HTMLをそのまま読み込んだ場合

ブラウザ 結果
IE8 問題なし
IE11 問題なし
Edge 問題なし
Chrome 問題なし
Safari 問題なし
Firefox 問題なし


IE8はContent-Type無視問題も存在するのでそのままXSSを実行してくれると思っていた。が実際にはXSSは対策されていた。

IE8_no_xss
IE8で検証した画面

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_otherOrigin
iframeが外部ドメインの場合

iframe_sameOrigin
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付与のクロスサイトスクリプティング脆弱性についての項目は
現場でセキュリティ担当者が複数のサービスに対してチェックする上で負担になる代物になっているのであれば
個人的にはフォローを外しても良い様な気がする。