Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話
2014-07-09 それぞれ修正されたのを確認したので追記します。
APSB14-17 で修正されたようです
筆者が把握している範囲で、最新版のFlash Playerを利用している場合に、(crossdomain.xmlもしくはユーザーの許可なしで)cross originでカスタムヘッダを付与する方法はありません。
Webサイト運営者は
ことを確認することで、(ブラウザやプラグインのバグが無い前提で) CSRF対策を行うことが出来ます。
古いバージョンのFlash Playerには、他にも任意コード実行を含む深刻な脆弱性を数多く抱えているため、アップデートが強く推奨されます。Webサイト運営者が古いFlash Playerに配慮したところで、利用者の安全性は高まりません。単にアップデート推奨しましょう。
修正されたため、以下、古いFlash Playerを使ってるユーザーを無視できない人向けの参考情報となります
この文章は2014-02-07に書かれました。あなたがこれを読むときには修正されているかも知れませんので注意してください。更新情報があったら追記するつもりですが、忘れてしまうかも知れません。
2011年2月 http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails/
2011年2月 http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html
Firefoxの場合: 確認が出ます。リダイレクトを許可してもカスタムヘッダは取り除かれます。
Opera12の場合: 確認が出ます。許可してもリクエストは送られません。
Chromeの場合: カスタムヘッダ付きでPOSTリクエストをリダイレクトします。originヘッダも付きます。
Safariの場合: カスタムヘッダ付きでPOSTリクエストをリダイレクトします。
カスタムヘッダがcross originで送信されてしまうのはセキュリティモデルに違反する、ということで
NPAPI(Netscape Plugin APIのことだよ)の拡張仕様が提案されて、Firefox4で実装された。
一度修正されてenbug?
NPAPI(段階的に廃止しようとしてるやつだよ)からPPAPIへの移行で問題があったんじゃない?とのこと
navigateToURLに // で始まるURLを指定することでもカスタムヘッダ付与が出来てしまう。
http://127.0.0.1/ から //example.com にリクエストを投げると
//local.example.com:5000/ のような指定だと失敗した。ポート番号が付くとダメらしい。
また、認証がゆるふわだけどブラウザからはカスタムヘッダつけられないから専用クライアントからじゃないと設定変更できないよね、という前提のプロトコルがルーターとかプリンタとかで使われていた場合には勝手に設定変更される恐れがあります。これはGoogle Chromeのケースでも影響があります。chromeはoriginヘッダ付けてくれますが、余計なヘッダとみなして無視されるでしょう。