パスワードを忘れた？ アカウント作成
Close
11487 story
Google

UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意 39

ストーリー by Acanthopanax
ここにも潜んでいたXSS 部門より

jbeef曰く、"本家に「Cross Site Scripting Discovered in Google」というストーリが掲載された。 これは、Web Application Security Consortiumが主宰するメーリングリストに投稿された記事を伝えるもの。その記事によると、Google.comにXSS（クロスサイトスクリプティング）脆弱性が見つかり、発見者が11月15日にGoogleに連絡したところ、12月1日に修正されたという。この脆弱性の原因と対策は以下の通り。" (つづく...)

"まず、Googleの404 Not Foundのページはこの例のように、リクエストされたURLのパス名を画面に表示するようになっている。ここで、そのパス名にHTMLのタグを構成する文字「<」「>」が含まれている場合、Googleは、これをきちんと「&lt;」「&gt;」にエスケープして出力するよう正しく実装していた。ところが、このページは当時、ページの文字エンコーディングを強制する指定をしていなかった。つまり、

Content-Type: text/html; charset=エンコーディング名
といった指定をHTTP応答のヘッダないし、HTMLの「<meta http-equiv="Content-Type" content="...」に記述することをしていなかった。Internet Explorerでは、ページのエンコーディングが指定されていない場合、データがUTF-7っぽい内容であれば自動的にUTF-7として表示する機能が働くため、UTF-7エンコードされたXSS攻撃文字列をURLに含めてGoogle.comの404 Not Foundページを表示させる攻撃がしかけられると、罠にかかった被害者のInternet Explorer上でJavaScriptコードが実行されてしまう。

Googleはこの指摘に対し、当該ページに「<meta http-equiv="content-type" content="text/html;charset=us-ascii">」を埋め込んでエンコーディングを明示するようにすることで、この問題を解決したようだ。

このような文字エンコーディングの曖昧さによって発現するXSS脆弱性の問題については、2000年の時点で既にCERT Advisory CA-2000-02で次のように勧告されていた。

web pages should explicitly set a character set to an appropriate value in all dynamically generated pages.
（Webページは全ての動的に生成されるページにおいて文字エンコーディングを適切な値に明示的にセットするべきである。 ）

2000年にリリースされたApache 1.3.12でも、404 Not Foundなどのエラーページで「charset=iso-8859-1」を明示する変更が加えられており、当時日本では、これによって文字化けが発生する不具合が生じたため、別の意味で話題となっていた。当時の様子は「Apache 1.3.12 文字化け問題」に見ることができる。

幸い日本では、日本語を使用する都合から文字エンコーディングを常に指定する習慣が元々根付いているため、この問題の影響を受けるところは多くないかもしれないが、念のため、エンコーディング指定のないページがないか確認しよう。

この問題はUTF-7固有の問題ではない。たとえばISO-2022-JPでも同様のことが起こり得る。ユーザが意図してメニューから文字エンコーディングを変更すると、それによってXSS攻撃が発動することがある。訪れたサイトで文字化けが起きているからといって、不用意にエンコーディングを変更してはいけない。「文字エンコーディングを変更してください」などと要求するページに騙されないよう注意が必要だ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意 More

  • 普通の文字化けと見分けは…… (スコア:2, すばらしい洞察)

    by koshian (6999) on 2005年12月22日 9時23分 (#853528) ホームページ 日記
    アタックコードの入ってない、本当にただの文字化けの場合と、どうやって見分けをつければいいんでしょうかね。
    エンコーディングを手動で指定するときはJavaScriptを切っておく、とかしかないのかな。

    だとすると、エンコーディングを変更したときにJavaScriptが動くこと自体を脆弱性として取り扱える……かな?

  • UTF-7エンコーディング (スコア:2, 参考になる)

    by tia (12881) on 2005年12月22日 10時25分 (#853576)
    UTF-7のエンコーディングについてはRFC2152 [rfc.net]に規定されています。ご参考に。

    • Re:UTF-7エンコーディング (スコア:2, 興味深い)

      by s-tomo (2841) on 2005年12月22日 11時45分 (#853652) ホームページ 日記
      rfcより、

      > Set O (optional direct characters) consists of the following
        (略
      >     Character   ASCII & Unicode Value (decimal)
        (略
      >       <           60

      UTF-7においては文字「<」をバイト値「60」として表現するのは「optional」。つまり、バイト値「60」ではない表現形式もあって、そっちの場合は「&lt;」に変換されないということか。

      今回はcharsetが明示されていなかったことが問題でしたが、「charset=UTF-7」を明示する場合には別表現の方もちゃんと扱わないとまずいですね。

      タレコミでは、

      > たとえばISO-2022-JPでも同様のことが起こり得る。

      とのことなのでISO-2022-JPの場合にもバイト値「60」以外の表現形式があるということと思われるが、
      Shift_JIS,EUC-JP,UTF-8では大丈夫なのでしょうか。

      charsetを指定することは大前提として、自分で指定したcharsetにおいて文字「<」が、どういう形で表現されうるか把握していないとハマルと思うねんけど。
      シェア
      親コメント

      • Re:UTF-7エンコーディング (スコア:3, 参考になる)

        by ruto (17678) on 2005年12月22日 19時41分 (#853919) 日記
        サーバーが文字列をISO-2022-JPとして処理してそれをクライアントがEUC-JPなどとして扱うとまずい、というのは考えられます。
        <html>
        <head>
        aaa<script>/*bbb*/function msg(){alert('xss');}</script>
        </head>
        <body>
        <button onclick="javascript:msg()">abc</button>
        </body>
        </html>
        というファイルを作り、aaaをESC $ B、bbbをESC ( Bとバイナリエディタで置き換えると、<script>/*の部分が「首竰蜷(文字化け)(文字化け)」という文字列になります。
        この文字列をサーバーがISO-2022-JPとして扱うと「首」に含まれる"<"はエスケープされませんが、クライアントがこれをEUC-JPとして扱うと「首」の部分は"<s"として扱われてしまいます。実際Firefox1.07では文字コードをEUC-JPなどとメニューから指定するとscript要素が有効になりました。

        あと、試してませんが、EUC-JPやShift_JISで2バイト目を<にした文字を入れて、それをISO-2022-JPとして解釈させると<として扱われる、というのもあるかもしれません。

        これの対策としては、サーバー側で、出力するエンコーディングにおいて0x3Cなどを含む文字を出力するときは数値参照に変換する、というのが考えられます。
        シェア
        親コメント
        • > あと、試してませんが、EUC-JPやShift_JISで2バイト目を ISO-2022-JPとして解釈させるととして扱われる、というのもあるかもしれません。 EUC-JP や Shift_JIS で、２バイト目が になることはないはずです。なので、 ESC にさえ気をつければよいと思っていたのですが... UTF-7 ... orz

      • UTF-7 と ISO-2022(-JP) は 7 bits 伝送経路に対応した文字セットで、7 bits で表現できる文字コード (ASCII キャラクタ、および制御コード) のみによって構成されています。

        これらの文字セットでは、8 bits 以上必要な文字を表現するため、特定の制御コードの出現を境に、文字コードをそのまま扱うモードと、エスケープされた表現によって文字コードを表現できるモードとを切り替えるように作られています。

        エスケープされた表現を用いて、< や > を記述することができてしまう、ということですね。

        Shift_JIS や EUC-JP 、UTF-8/16 などには、このような機能は無い (無くても十分なコードが表現できる) 文字セットなので、同様の脆弱性を心配する必要は無い、ということなんだと思います。

        # 文字セットについてはこの辺 [euc.jp]とかの説明がわかりやすいかと。つか、走り書きゆえ、用語の厳密さとかはかなりいい加減っす m(_ _;)m

        # つか、おいらも気付かんかたーよこんな危険性 (^_^;;

        --
        むらちより/あい/をこめて。
        シェア
        親コメント

  • オフトピ: Apache 1.3.12 文字化け問題 (スコア:2, 興味深い)

    by magicalchalk (27784) on 2005年12月23日 19時17分 (#854377)

    「Apache 1.3.12 文字化け問題 [asahi-net.or.jp]」より。

    Netscape 4.x の charset の扱いについてのバグ

    301 や 401 の後に表示するページの META タグにいかなる charset が設定されていても、そのページ直前の (301 や 401 の) HTTP レスポンスで返された charset のほうを見てしまう、という バグが Netscape 4.x にはある。リロードした場合など、キャッシュ から読みこむ場合にはMETA タグのほうを読みにいくので問題はな い。

    これついては Netscape 4.x の問題といえるし、一番の原因だろう。

    W3C HTML 4.01 勧告(リンク先は和訳) [asahi-net.or.jp]に HTTP レスポンスヘッダは HTML 文書内の META 要素に優先すると書いてある。バグではないし仕様が腐っているわけでもない。キャッシュから読み込んだときに META 要素が優先されたらかえってやばいと思うけど。

    • キャッシュから読み込んだときに META 要素が優先されたらかえってやばいと思うけど。
      cacheから読み込んだときは、cache上のHTMLテキストが使われるわけで、そのエンコーディングはMETA要素と一致させれているはずなのだから、METAを使う方が危なくないですよね。

      2回アクセスしたとき、1回目と2回目でサーバの応答のエンコーディングが異なっている場合、HTMLテキストはcacheから読んで、エンコーディングは2回目の応答ヘッダから読むという、そのW3C HTML 4.01勧告の方が危険な仕様ではないですかね。

    • うはw 馬鹿2名発見！

  • Webメール (スコア:1, 興味深い)

    by Anonymous Coward on 2005年12月22日 10時26分 (#853577)
    その危険性は認識してなかった……。＞文字エンコーディング変更
    海外のWebメールサービスを利用していると、日本語が文字化けして読めないことが往々にしてある（とゆか、素で読める方が少ないｗ）んで、無頓着にエンコーディングを変更してましたが、これからは気をつけたほうがいいのかな。
    でも、往々にしてそういうサイトはJavaScriptを切ると動作しないので、対処の方法が……。orz

    微妙にオフトピック気味ですが、UTF-7って複雑過ぎる規格ですよねー。
    エスケープがあるから、UTF-8とは使い勝手が全く異なるし。
    IETFでも非推奨扱いのようですから、早くこの世から消滅してほしいです。:-)

  • 関連報道 (スコア:1, 参考になる)

    by Anonymous Coward on 2005年12月23日 12時21分 (#854253)

  • 被害者 (スコア:0, フレームのもと)

    by Anonymous Coward on 2005年12月22日 9時04分 (#853516)
    >>罠にかかった被害者のInternet Explorer上でJavaScriptコードが実行されてしまう。

    IEなんか使うからいけないんだよ。

    • Re:被害者 (スコア:3, 参考になる)

      by hsgw (14585) on 2005年12月22日 13時47分 (#853752)
      この問題はIE固有の問題ではない。たとえばFirefoxでも同様のことが起こり得る [hacker.jp]。ユーザが意図してメニューから文字エンコーディングを変更すると、それによってXSS攻撃が発動することがある。訪れたサイトで文字化けが起きているからといって、不用意にエンコーディングを変更してはいけない。
      シェア
      親コメント

      • Re:被害者 (スコア:2, 参考になる)

        by Anonymous Coward on 2005年12月22日 14時14分 (#853774)
        この問題に関してはFirefoxのほうが危険な面もあります。
        Internet Explorerは、UTF-16、UTF-7、ISO-2022-JPなどの「危険」なエンコーディング(1バイトの0～0x7f以外のものがASCIIと解釈されうるエンコーディング)はユーザーの指定では選択できないようになっています。
        まあタレコミのようなUTF-7っぽいものをUTF-7と勝手に判別させる攻撃があるし親コメントのようなShift_JISに変えると発動するトラップも作れるのでIEなら安心なわけでは決してありませんが。
        シェア
        親コメント

        • Re:被害者 (スコア:2, 興味深い)

          by mnakano (27173) on 2005年12月24日 1時51分 (#854548)

          Internet Explorerは、UTF-16、UTF-7、ISO-2022-JPなどの「危険」なエンコーディング(1バイトの0～0x7f以外のものがASCIIと解釈されうるエンコーディング)はユーザーの指定では選択できないようになっています。

          日本語に関してはそうですが、中国語のHZはそうではありません。選択できてしまいます。

          Internet Explorerのこのメニュー構成が果たして、こういう問題を想定してのものかどうかについては疑問に感じます。

          もしこの問題を予見していたのであれば、そもそも文字コードの自動検出からもこれらの文字コードを候補からは外しておくべきです。(単に開発者が異なっていて、連携がとれていないだけかもしれませんが、それはそれで問題。)

          Mozilla関連プロダクトでもBugzilla-jpで意見を募っています [mozilla.gr.jp]。

          シェア
          親コメント

    • 予言成就 (スコア:1, 興味深い)

      by Anonymous Coward on 2005年12月22日 10時59分 (#853614)
      確かに書き方は「フレームのもと」かもしれませんが、
      現実的な解としては「あり」だと思います。
      シェア
      親コメント

    • 予言 (スコア:0, おもしろおかしい)

      by Anonymous Coward
      ここで、「上のコメントには『フレームのもと』が付いてますが、この方の言う事も尤もですよ」的な意味合いの煽りコメントが付く。
      ↓

      • Re:予言 (スコア:0)

        by Anonymous Coward
        なにその必死な予防線はw
        そんなに嫌なのかw

  • 教唆 (スコア:0)

    by Anonymous Coward on 2005年12月22日 9時25分 (#853529)
    >念のため、エンコーディング指定のないページがないか確認しよう。

    もちろん、自分で管理するコンテンツで、ですよね。

  • 僕の場合常に (スコア:0)

    by Anonymous Coward on 2005年12月23日 12時03分 (#854249)
    AddDefaultCharset noneを指定しているので万全です。
  • ステートフルだから、デコード、エンコード、エスケープまわりにセキュリティホールが隠れていそうです。
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson