XSSフィルタはきりがない | 水無月ばけらのえび日記
歴史的経緯を振り返ってみても、HotmailやYahoo! Mailなど、HTMLメールに対応したWebメールが90年代から繰り返しこの種の原因による脆弱性を指摘されてきましたが、発見者達は言外に「このような作り方はやめるべきである」という主張を含んでいたのだろうと私は思います（し、私が指摘したものについてはそのような意図を含んでいました）。しかしながら、そうした脆弱性を指摘されたサービス提供者たちは、根本的な解決を選択せずに、フィルタリング方法のその場しのぎの改善を繰り返して現在にまで至っています。 そうですねぇ。 いつぞやの講演でも言ったと思いますが、指摘→修正→別の方法で貫通することを指摘→修正→別の方法で貫通することを指摘……などという経験をすると、本当にあほらしく思うわけでして。 「XSSフィルタはきりがない」へのコメント (5件)関連する話題: セキュリティ
HTMLタグを許可するWebアプリケーションでの検査 - 葉っぱ日記
イベントハンドラ等でのスクリプトを禁止するために、"javascript" や "vbscript" のような、ブラックリストに合致する文字列が含まれているかどうかを検査する方法では、XSS は防げません。 例えば <div onclick="javascript:alert('xss')">aa</div>という典型的な XSS パターンに対し、"javascript" という文字列を禁止文字列として検査対象にしている場合、以下のような入力を与えることで検査を回避し、スクリプトを動作させることができます(IE6およびFirefox 1.5で確認)。 <div onclick="alert('xss')">aa</div> <div onclick="http:alert('xss')">aa</div> <div onclick="http:/**/alert('xss')">aa</d
Cross Site Tracing | 鳩丸ぐろっさり (用語集)
用語「Cross Site Tracing」についてCross Site Tracing (くろすさいととれーしんぐ)話題 : セキュリティ クロスサイトスクリプティング脆弱性などを利用して TRACE メソッドのリクエストを発行させ、HTTP要求ヘッダの内容を読み取る手法のことです。これによって Authorization フィールドの内容を読み取り、Basic 認証のパスワードを盗むことができます。 通常、クロスサイトスクリプティング脆弱性を利用した攻撃では Cookie の内容を読み取ってセッションハイジャックを行うことが想定されます。Cookie の内容はスクリプトから簡単にアクセスできます。クロスサイトスクリプティング脆弱性によって任意のスクリプトが実行できるようになっていると、Cookie は簡単に盗まれてしまいます。 それに対して、Cookie を使用せずに Basic 認証
CSSクロスドメインの情報漏えいの脆弱性「CSSXSS」とは ― ＠IT
あるWebページにアクセスしたら、自分のYahoo! JAPAN IDやHatenaのID、mixiで使っている名前などが表示された。何の縁もゆかりもないページにこれらのプライベートな情報がなぜ表示されてしまったのだろうか。 これは「CSSクロスドメインの情報の漏えいの脆弱性（CVE-2005-4089）」という、Webブラウザがスタイルシート（CSS）を呼び出す機能にある脆弱性を利用した攻撃だったのだ。この脆弱性は通称「CSSXSS（CSS Cross Site Scripting）」とも呼ばれている。 CSSインポート時にCSS以外のファイルがテキストとして読み込める 最近のWebページは、文書の構造をHTML形式で記し、フォントや色やレイアウトなどの視覚的な表現をスタイルシートで記述するというHTMLの仕様に従っていることが多い。 HTMLファイルから外部のスタイルシートを呼び出すた
■ - 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:
はてなブログ | 無料ブログを作成しよう
新米と秋刀魚のわた焼き お刺身用の秋刀魚を買いました。1尾250円です 3枚におろして、秋刀魚のわたに酒、味醂、醤油で調味して1時間ほど漬け込み、グリルで焼きました 秋刀魚のわた焼き わたの、苦味が程よくマイルドに調味され、クセになる味わいです 艶やかな新米と一緒に 自家製お漬物 土…
サニタイズと言わない
(Last Updated On: 2006年1月3日)珍しくサニタイズという考え方自体が間違っているという意見を見ました。 私もサニタイズと言う考え方はNagative Security（禁止事項を定義する考え方）からの発想なので、Positive Security（許可する事項を定義する考え方）でプログラムを作るべきと考えていますし、あちらこちらで言っています。この高木さんのブログのでは、デフォルトのコーディングスタイルではサニタイズを考えなくても良いようにする事、と意見されているだと思います。いちいち意識しなくても良いようなスタイルの方が間違いが少なくなるので良いことだと思います。 # Googleで調べるとNagative/Positive Securityの方がよく利用され # ていることが分かりますが、個人的にはNagative/Positive Security # と言って
文字コードとHTMLエンコードとCross-Site Scriptingの微妙な関係 - 交差点でコーヒーを
もっといっぱい動くっぽかった。まとまったら後で書くですよ。っていうか、対策としてそういう条件を強いるのはなんだかなぁな位幅が広いかも？*1 ダメだった……。残念。次はEUC調べよっと。 EUCの場合 脆弱なコード例(もちろん文字コードはEUCで) <form> text: <input type='text' name='text' value="<?= htmlspecialchars($_GET{'text'}) ?>"><br> text2: <input type='text' name='text2' value="<?= htmlspecialchars($_GET{'text2'}) ?>"><br> <input type=submit value="送信"> </form>攻撃例*2 http://localhost/break_quote_euc.php?text=te
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'}) ?>"
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
こめんと(2005-07-18)
■ [Security] [Comp] Cross-site scripting と Hungarian-notation 僕個人は所謂 Hungarian-notation (型名の省略形を変数名前の頭に付ける記法) は 大嫌いなのだが、最近いろいろな Web プログラムのソースファイルを見ていて、 ひょっとしたら（あくまで過渡的に）最近の web プログラミングに於いては 実践すべきなのではないのか、という気がしてきた。 といっても、別に整数とか長整数とか、まして「ゼロ終端文字列へのロングポインタ(lpsz)」 なんてタグをつけろというわけではなくて、最近流行りの Web 系の脆弱性に応用する話。 というか、危険なプログラム書くよりはHN使う方がマシ。 でもやっぱり嫌だなぁ……。 Hungarian-notation を否定する時に一番楽な言い方ってのは、 ってなわけですが、良くありが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JVN#51301450: NetCommons におけるクロスサイトスクリプティングの脆弱性