UTF-16の動的コンテンツにおけるXSS - masa141421356’s blog
charset指定を明示しない動的なUTF-16のHTMLでは、 動的に生成した部分に1バイトで文字を表現できるエンコーディングで HTMLのタグと認識できるようなバイト列を注入することでXSSが成立する。 例： UTF-16（BE,BOMなし)で生成されるレスポンスが <html><head> <title>ユーザー入力文字列</title> </head> <body>AA</body></html>の場合。(便宜上改行していますが実際には改行されていないものと思ってください） ユーザー入力文字列のUTF-16でのバイト列が hex表記で 3C 2F 74 69 74 6C 65 3E 3C 73 63 72 69 70 74 3E 61 6C 65 72 74 28 64 6F 63 75 6D 65 6E 74 2E 63 6F 6F 6B 69 65 29 3C 2F 73 63
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
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が不明瞭な場合、罠ページ内でターゲットとなるページを
安全なウェブサイトの作り方 改定第3版 - 葉っぱ日記
IPAによる「安全なウェブサイトの作り方」の改定第3版が出ていました。あちこちにUTF-7によるXSSネタが出てきているんですが、いくつか気になる点がありました。 まずはP.25から。 HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type:text/html; charset=us-ascii」のように、文字コード(charset)を指定することができますが、この指定を省略した場合… 安全なウェブサイトの作り方 改定第3版 (P.25)より。charset をきちんとつけようという例で US-ASCII を示すのはあまり頂けないなと思います。Internet Explorer においては、US-ASCIIの場合は最上位ビットを無視するという問題が2006年から放置されてますので、US-ASCIIを指定してもそれはそれでWebアプリケーション開発
文字コードとXSS - おおいわのこめんと(2005-12-26)
■ [Security] 文字コードとXSS (書きかけ) 例によってセキュリティホールmemoより。厄介ですねぇ……。 キチンと全文書に文字コード指定をしておく マイナーな文字コードで送信するときは、対応環境と影響を考えておく。 不安なら ASCII 完全上位互換の文字コード (ASCII の有効バイトは常に ASCII と同じ意味を持つ EUC-JP、UTF-8 など) を使う。 cross-site injection で META が埋め込めるとかは論外。 位は比較的簡単だし、やっておかないといけないかな。 で、ちょっと気になっているのとしては、とりあえず、UTF-7 はやばやばなのは明らかとして、 ISO-2022-* への派生している議論はちょっとずれている気がしている。 とりあえず、 Bugzilla.jp の 4868: ASCIIと互換性のない文字コードはユーザーの指定で
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
19. マルチバイト文字とXSS脆弱性
比較的新しい攻撃方法に、不完全なマルチバイト文字列を送信することでHTMLに 記述されているクォートを無効化する方法があります。この攻撃はHTML エス ケープのみでは防げない事に注意が必要です。では、どのように対策をすれば良 いのでしょうか？ まずは、不完全なマルチバイト文字を利用してクォート（"）を無効化できるこ とを確認しましょう。次のスクリプトをブラウザから実行して下さい（最後の ダブルクォテーションとPHPタグの間にスペースを入れないで下さい）。 <?php $str = urldecode('%81'); header('Content-Type: text/html; charset=SJIS'); ?> <?php echo htmlentities($str, ENT_QUOTES, 'SJIS') ?>" コードが分かりづらいので注意してください。PHPタグを２つに大別
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
■ - hoshikuzu | star_dust の書斎
■IEにおいてUS-ASCIIなエンコーディングでXSS発生？ US-ASCII な記述で、<,>,", のフィルタリングを回避可能かもの実証コード(IEのみが脆弱) ちょっと古いハナシなのでしょうけれど。 ASCII Test: www.iku-ag.de 原因はどこにあるのか 上記実例にてサーバからのHTTP応答ヘッダを見てみると。 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 ETag: W/"428-1150936271000" Last-Modified: Thu, 22 Jun 2006 00:31:11 GMT Content-Type: text/html Content-Length: 428 Date: Sat, 24 Jun 2006 13:59:01 GMT 上記の応答には、特徴的なことがあります。 Content-Type:
2006-03-27
今年は1回しか花粉症で薬飲んでません。昨日、ニュースでスギ花粉のピークは終わったって言ってました。住んでる場所によるのかな？ 根が深い。（ぇ 文字コード（SJIS）とHTMLエンコードとCross-Site Scriptingの微妙な関係 もしかしたら周知の事実で私だけ遅れてるのかもしれないけど、メモってことで。IE限定。 PHPでHTMLエンコードされてるサンプルコードを書いてみた。 サンプルコード（SJISで保存してください） <form> text: <input type='text' name='text' value="<?= htmlspecialchars($_GET{'text'}) ?>"><br> text2: <input type='text' name='text2' value="<?= htmlspecialchars($_GET{'text2'}) ?>"
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://openmya.hacker.jp/hasegawa/public/20071107/s6/h6.html?file=data.txt