第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］ | gihyo.jp
前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
Inline UTF-7 E4X javascript hijacking
Inline UTF-7 E4X javascript hijacking Tuesday, 24 February 2009 I finally get to talk about this because Yosuke Hasegawa has already disclosed the IE/FF variant with JSON data. I also discovered the UTF-7 JSON hacking independently but I wasn’t aware it was public so I didn’t blog about it. Just in case you haven’t, you should check out his presentation it’s awesome! Anyway onto E4X I just love it
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
UTF-7でスクリプトを実行させるXSSについて
IEでUTF-7なスクリプトをiframeの中に表示するとXSSが発生するメモです。 あんまりこの話には詳しくないので、今後の調査材料として残しときます。 （※一応悪用厳禁であります！） iframe内のエンコードが正しく指定されていない場合は、そのiframeの親にあたる部分のエンコードが自動的に適用されるというIEのバグがあるみたい。 今回はそれのちょこっとした検証！ 1番初めに呼ばれるhtml（①.html） <html> <head> <title> </title> </head> <body> <script type="text/javascript"> window.onload = function(){ var iframe = document.createElement('iframe'); iframe.src = '/utf7XSS/utf7XSS'; docu
Namazu: セキュリティに関する考察
基本方針 最新版はおそらく安全だとは思いますが、確実とは言えません。 Namazu は完全に無保証です。すべてあなたの責任のもとに運用し てください。ただし、セキュリティの問題にはできる限り対応する つもりです。まずい点を見つけたら連絡してください。 既知の問題 2.0.20 または 2.0.20 より古いヴァージョンには、 IE6,7の脆弱性対策ができていません。 このため Namazu 2.0.21 以降を利用することを推奨します。 2.0.19 または 2.0.19 より古いヴァージョンには、 バッファオーバーランの脆弱性があります。 2.0.17 または 2.0.17 より古いヴァージョンには、 Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディングされた検索式の脆弱性があります。 2.0.15 または 2.0.15 より古いヴァージョンには、ディレクトリト
[技術資料] Namazu 2.0.18 に新設された Charset ディレクティブ関連の話: ナマズのブログ
Namazu 2.0.17 以前の namazu.cgi はデフォルトではレスポンスヘッダの ContentType に charset を出力しません。 この時、Web ブラウザの charset 自動認識の誤認により脆弱性の問題が 起こることがあります。 http://www.namazu.org/security.html しかし、Namazu 2.0.6 以降には namazu.cgi で出力するレスポンスヘッダの ContentType を .namazurc で直接指定する機能を有しています。 ContentType "text/html; charset=EUC_JP" など明示的に指定することでレスポンスヘッダの ContentType に charset を 出力することができ、この脆弱性の問題を回避することができます。 ただし、この場合は charset の値が固定され
UTF-7によるXSSからの防御方法 - 葉っぱ日記
たぶん UTF-7 XSS Cheat Sheet を読んだ人の感想: http://twitter.com/nyaxt/statuses/596330132より 残念ながら違います。伝え方がヘタクソでごめんなさい。 UTF-7によるXSSを防ぐには、以下の対策をとれば大丈夫です。 文字エンコーディング(charset)を明示する(できればHTTPレスポンスヘッダがよい) HTTPレスポンスヘッダではなく、<meta> で指定する場合には、<meta> より前に攻撃者がコントロール可能な文字列をおかない 指定する文字エンコーディング名は、ブラウザが確実に認識できる名称とする この3点を守っている限り、UTF-7を利用したXSSは発生しません。 iframeを使用するのは、攻撃者の作成した罠ページです。ターゲットとなるページのcharsetが不明瞭な場合、罠ページ内でターゲットとなるページを
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
UTF-7 XSS Cheat Sheet
Countermeasures against XSS with UTF-7 are: Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. For more information about UTF-7 trick, see "Cross-site scripthing with UTF-7". These XSS patterns are tested on IE6 and IE7. Yosuke HASEGAWA <hasegawa@openmya.hacker.jp> Last modified: 2008-01
続: そろそろUTF-7について一言いっとくか - 葉っぱ日記
史上空前のEUC-JPブームはとりあえずおいておいて、今日も最強の文字コードであるUTF-7について。 これまで私の中では、UTF-7によるXSSを避けるためには、Shift_JISやUTF-8といった、IEが受け入れ可能なcharsetをHTTPレスポンスヘッダまたは<meta>で明記してやればよいという理解でした。 具体的には、HTTPレスポンスヘッダで Content-Type: text/html; charset=Shift_JIS とするか、生成するHTML内で <meta http=equiv="Content-Type" content="text/html; charset=Shift_JIS"> とすれば、UTF-7によるXSSは防げると思っていました。ところが、後者の<meta>によるcharsetの指定では、条件によってXSSが防げないことがあるということに気付きま
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
未知のぜい弱性を発見した。どーすんの！？オレ（その1）
いきなり質問です。未知のぜい弱性を発見したら皆さんはどうしますか？ 自分が未知のぜい弱性を発見することは無いと思われているかもしれませんが，じつは身近に存在しているのに今は気付いていないだけかもしれません。皆さんがぜい弱性を発見して報告する日は近いかもしれませんので，今回は私の経験を基にぜい弱性を発見したらどうするかについて書きたいと思います。 私は今までに何件かぜい弱性を発見して，ソフトウエアの開発元に報告したことがあります。最近では「MS06-053」（http://www.microsoft.com/japan/technet/security/bulletin/ms06-053.mspx）で修正されたぜい弱性を報告しました。まずは，このぜい弱性の発見から報告までの流れを説明しましょう。 2005年12月に「www.google.comにクロスサイト・スクリプティングのぜい弱性，米W
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://openmya.hacker.jp/hasegawa/public/20071107/s6/h6.html?file=datae.txt
http://openmya.hacker.jp/hasegawa/public/20071107/s6/h6.html?file=data.txt
NVD - CVE-2007-5415