第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要
セキュリティ情報 - UTF-8を利用したIDS/IPS/WAFの検知回避技術
UTF-8を利用したIDS/IPS/WAFの検知回避技術 HASHコンサルティング株式会社 公開日:2009年3月23日 概要 本レポートでは、ASP.NET(1.1)をUTF-8文字エンコーディングにて利用しているサイトにおいて、不正な文字エンコーディングを利用したIDS/IPS/WAF回避の可能性について報告する。 背景 株式会社ラックが2008年10月に「【CSL】CSL緊急注意喚起レポート～新手のSQLインジェクションを行使するボットの確認～」と題するホワイトペーパーを発表した。いくつかの新種の攻撃手法が説明されている中で、不正なパーセントエンコードを利用した検知回避テクニックについて言及している。具体的には、以下のような方法だ。 Active Server Pages(ASP)では、「DEC%LARE」のようにパーセント記号に続く2文字が16進数でない場合、パーセント記号を
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
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 より古いヴァージョンには、ディレクトリト
2008-01-18 - hoshikuzu | star_dust dairy - about UTF-7 XSS Cheat Sheet
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
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
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
Atom や RDF を利用したXSS - 葉っぱ日記
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
葉っぱ日記 - レジストリの 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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
