Masato Kinugawa Security Blog: MS13-037: エンコーディングの自動選択の強制によるXSS
2013年5月の月例パッチ、MS13-037で修正された、Internet Explorerでエンコーディングの自動選択を強制的に起こせたバグについて書きます。 http://technet.microsoft.com/ja-jp/security/bulletin/ms13-037 このセキュリティ情報に組み込まれている多層防御についてマイクロソフトと協力してくださった Masato Kinugawa 氏 アドバイザリには問題に対する説明がありませんが、多層防御で修正されたのがこの問題です。 今回は、ざっと、報告書っぽく。 -------------------------------------------- 報告日： 2012年11月23日 問題の概要： IEで特定の方法でページを表示しようとすると、ページのエンコーディングの指定にかかわらず、ページに含まれるバイト値からブラウザ側で
UXSS – Internet Explorer EUC-JP Parsing Bug
While I was using shazzer, one vector had a really weird result. The vector was: <img src=x *chr*> onerror=alert(1)>; The result said that in Internet Explorer 10, a certain character in the euc-jp charset consumed the >, which lead to the execution of the onerror event handler but viewing the test case resulted in no code execution. After retesting the vector, there were either no results or diff
Masato Kinugawa Security Blog: 各ブラウザがサポートするcharsetのリスト
メジャーブラウザがサポートするcharsetのリストを個人的に調べてまとめたので公開します。 正式名とエイリアスのリスト http://l0.cm/encodings/list/ 表にしたもの http://l0.cm/encodings/table/ charsetの発見は以下のようにして行いました。 1. charsetとして認識してくれそうな文字列をウェブからかき集める。 2. Content-Typeヘッダのcharsetの値に、集めた文字列から1つ選んで指定し、bobyには、<meta charset="iso-2022-jp">を含んだページを作る。 3. 2で作ったページをフレームに読み込み、親フレームからJavaScriptでフレームに設定されたcharsetの値を読み取る。 4. 取得されたcharsetの値により以下のAかBの判断/処理をする。 A. iso-2022-
Masato Kinugawa Security Blog: OperaのEUC-TWに存在した潜在的にXSSが可能な問題
安定版Opera 12.10で修正されているのを確認したので書きます。 ベンダは悪用は難しいとして、これをノーマルバグとして扱いましたが、修正前はcharset指定がないページやEUC-TWエンコーディングのページでXSSを引き起こす可能性がありました。 これを見つけた経緯から話すと、僕は以前から、ブラウザがサポートするエンコーディングのページで、「0x22」「0x26」「0x27」「0x3C」「0x3E」「0x5C」("&'<>\)などの特殊な文字がマップされているバイト値を除いた上で、ランダムにバイト列を表示させて、別のバイト列で「"&'<>\」が現れないかチェックするというような、ブラウザのセキュリティバグを発見するためのテストを行っていました。これにより、OperaのEUC-TWで「"<>」などを検出し、この問題を発見しました。 実はこの手法で他のブラウザでもいくつかの問題を検出し
JavaScriptの文字列リテラルでXSS - T.Teradaの日記
たまに以下のようにJavaScriptの文字列リテラルに値が入るアプリを見ることがあります。 <script> var foo="●"; ... </script> 値は「●」の箇所にHTMLエスケープされて出力されます（下の方の例も同じ）。 こんなケースでどうXSSするか？という話です。 簡単にXSSできるケース 以下のパターンだとXSSするのは簡単です。 <script> var foo="●"; var bar="●"; ... </script> ?foo=\&bar=-alert(123)//のような値を与えるだけです。 難しいケース 次はこんなパターンを考えます。 <script> var foo="●"; var bar="●"; ... </script> こうなると難易度はぐっと上がります。というよりも、ほとんどの場合はXSSできません。 しかし、状況次第ではXSSできる
Rails 2系のXSS脆弱性がRuby 1.9では影響なしとされる理由 - 岩本隆史の日記帳（アーカイブ）
Rails 2系のXSS脆弱性を修正するパッチが先日公開されました。 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。 http://journal.mycom.co.jp/news/2009/09/07/048/index.html この件に関して、大垣さんは次のように説明しています。 RoRの脆弱性に関連してRuby1.9では安全、と解説されていますが、それはRuby1.9は不正な文字エンコーディングを受け付けないからです。 何故かあたり前にならない文字エ
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
第21回 文字エンコーディングとセキュリティ（3） | gihyo.jp
前回に引き続き、今回も文字エンコーディングとセキュリティをテーマに解説します。前回は壊れた文字エンコーディングを利用した攻撃、文字エンコーディングを誤認識させる攻撃を紹介しました。今回はSJIS特定の問題を簡単に紹介します。 文字エンコーディングのエスケープ方式を利用する方法 ほとんどの文字エンコーディングは、マルチバイト文字の中に“\”などの特殊文字を含みません。しかし、例外があります。Shift_JISでは“\”がマルチバイト文字に含まれるので、これが原因で脆弱性が発生する場合あります。 SJISの“表” <?php echo rawurlencode(mb_convert_encoding('表', 'SJIS', 'UTF-8')); ?> 出力 %95%5C “%5C”は“\”です。“\”は文字列のエスケープなどに利用される特殊文字です。addslashes関
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bug 601429 – x-mac-arabic, x-mac-farsi and x-mac-hebrew are vulnerable to XSS
ma<s>atokinugawaの日記