mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 IEのためだけの問
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
ブラウザでJavaScriptが動く時代がやってきた！ - 葉っぱ日記
というわけで、昨日から話題沸騰の Javascript PC Emulator すごいですね。JavaScript で書かれた x86 PC エミュレータ上で Linux 動かして、入ってる tcc 使えばそこそこのソースもコンパイルして動いたり。 もとのディスク容量が少ないので、適当な母艦を用意して、こんな感じ で新しいディスクイメージ作って、CocProxy や Fiddler の AutoResponder を使って root.bin へのリクエストをローカルのファイルに差し替えてやれば、好きなファイルも入れられますね。 というわけで、SpiderMonkey を入れて動かしてみました。ブラウザ内でJavaScriptが動くなんてムネアツですね！ 手順としては、コンパイルの簡単な SpiderMonkey 1.7 を x86 の32ビットマシンで -static 付きでビルドして、r
IEのローカルファイルをXHRでどこまで読みとらせるか - 葉っぱ日記
ローカルのHTMLファイルからどこまで読み取れるか選手権 2011 - 金利0無利息キャッシング – キャッシングできます - subtech を読んでの補足。 IE9 on Windows 7 においてXHRを使ってローカルファイルを読み取る場合について、「許可するとやりたい放題」と書かれているとおり、IEが表示する警告をいったん「許可する」側に選択するとhtml内の JavaScript (あるいはVBScript)において通常のローカルのプログラムと同様にあらゆる操作が可能になります。(写真は英語版IE9) これは、IE6 / XP SP2 以降で導入された「ローカルコンピュータのロックダウン」が解除された状態になり、WSHやHTAと同様に、ローカルリソースへのアクセスや任意のActiveX Objectの生成を含め任意のコード実行が可能な状態になったということです。 ローカルに置い
1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
IE8 XSS Filterの仕様が微妙に変更されていた。 - 葉っぱ日記
先日、Google 日本語入力のHTTPを見てた id:tokuhirom さんに、HTTPレスポンスヘッダに「X-XSS-Protection: 1; mode=block」というのが含まれるというのを教えてもらったけど、"mode=block" というのが何か分からなかったので調べてみた。 結論としては、今月3月のセキュリティ更新 マイクロソフト セキュリティ情報 MS10-018 - 緊急 : Internet Explorer 用の累積的なセキュリティ更新プログラム (980182) で追加された機能だった。 この累積的な更新プログラムには、そのほかのセキュリティ関連の変更が含まれますか? この更新プログラムには X-XSS-Protection HTTP ヘッダーへの多層防御の更新が含まれています。具体的には、新しい "mode=block" 構文により、非継続的な誘導によるクロ
C# で Acme::x86::CPUID を作りました - 葉っぱ日記
C#のように実行環境が高度に抽象化された言語でプログラミングしているとき、実行マシンのCPUを判別してプログラムの処理を分岐したいときがよくでてくると思います。 そういうときに困ってしまわないように Acme::x86::CPUID みたいなのを作ってみました。 using System; using System.Runtime.InteropServices; class Acme_x86_CPUID { [DllImport("user32")] private extern static UInt32 EnumWindows(UInt32 p, UInt32 lParam); [DllImport("kernel32")] private extern static UInt32 VirtualAlloc( IntPtr lpAddress, UInt32 dwSize, UInt
www.microsoft.com におけるオープンリダイレクタ - 葉っぱ日記
やっぱり企業としては、こういうのあるのは頂けないよね。中の人いわく「弊社の Web サイトのリダイレクタが不正利用されていることを確認させていただきました。」だそうで。2008年12月26日に届け出、2008年12月29日に修正完了。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
