オープンリダイレクト検査：Locationヘッダ編 - T.Teradaの日記
オープンリダイレクタを脆弱性とみなすべきかは議論が分かれるところです。Google等の一部のサイトは、自サイトのオープンリダイレクタを脆弱性としてはみていません。一方で、脆弱性検査の現場では、見つかれば脆弱性として報告することが多いと思います。 その辺の議論はおいておいて、オープンリダイレクタの検査は、ブラウザの特性もからんで意外とバリエーションが多くて面白いので、本日の日記で取り上げてみたいと思います。 大まかにいうと、リダイレクトは、302応答のLocationヘッダ、Refresh（HTTPヘッダ、METAタグ）、JavaScriptによるものがありますが、本日は302応答のLocationヘッダのリダイレクタについて取り上げます。 パターン1：サブドメイン部分に値が入る場合 以下のように、サブドメインの箇所が動的なケースです。 Location: http://{$u}.haten
GoogleのReward Program - 2011-02-06 - T.Teradaの日記
少し前の話ですが、Googleが自身のWebサイトの脆弱性発見者に対して、報酬（現金 500 USD以上）を支払うプログラムをはじめています。 Google Online Security Blog: Rewarding web application security research 過去にも、脆弱性の発見者に報酬を支払うプログラムはありましたが、Webブラウザ等のソフトウェアの脆弱性が対象でした（参考）。 今回のプログラムでは、Webアプリの脆弱性が対象だというところが特色です。しかも、実際に運用されている本番のGoogleサイトの脆弱性が対象です。その脆弱性の発見者に報奨金を払うということは、（一定の制約は設けていますが）基本的に自由に本番サイトの検査をしてよいといっているわけです。 実際にやってみる Webアプリの診断をやっているものにとっては、これ以上のお小遣い稼ぎはない！と思
JavaScriptの文字列リテラルでXSS - T.Teradaの日記
たまに以下のようにJavaScriptの文字列リテラルに値が入るアプリを見ることがあります。 <script> var foo="●"; ... </script> 値は「●」の箇所にHTMLエスケープされて出力されます（下の方の例も同じ）。 こんなケースでどうXSSするか？という話です。 簡単にXSSできるケース 以下のパターンだとXSSするのは簡単です。 <script> var foo="●"; var bar="●"; ... </script> ?foo=\&bar=-alert(123)//のような値を与えるだけです。 難しいケース 次はこんなパターンを考えます。 <script> var foo="●"; var bar="●"; ... </script> こうなると難易度はぐっと上がります。というよりも、ほとんどの場合はXSSできません。 しかし、状況次第ではXSSできる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
