RefererによるCSRF対策の根拠 - masaのメモ置き場

高木浩光＠自宅の日記 - 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない, 駄目な技術文書の見分け方その1の2
この前書いたのは、読み違えでぼろぼろだったので、もう一度よく考えてみました。

つまり、リンクをクリックしてのジャンプかどうかは規定にないものの、ジャンプ先のURLが書かれているページがURLとして存在していない限り、Refererを送信してはいけない、つまり、少なくとも、任意のURLを Referer として送信することはしてはいけないことになっている。

RFC2616の記述から、「少なくとも、任意のURLを Referer として送信することはしてはいけないことになっている。」の結論をMust Notの動作として導き出していることに疑問があります。
（例えばユーザのキーボード入力のような）という補足が示すとおり「それ自身のURIを持たない出所から得られたもの」の記述は、ブラウザのアドレスバーの直打ちや、ブックマークからのアクセス時の挙動に関する定義であるでしょう。このケースでは、セッションIDがURLに含まれていた場合にセッションIDが漏洩する、といったセキュリティ上の問題が発生する可能性があります。同じくRFC2616におけるRefererに関するセキュリティ上の問題点に関する記述をみても、そういった可能性を考慮していることが分かると思います。

この記述を、

存在しないURIからはRefererを送信してはならない
従って存在しないURIをRefererとして送信してはならない
存在しないURIが設定出来るため、Refererには任意の値を設定出来てはならない

という論法で拡大解釈することは間違いであると考えます。(ここは推測ですが・・・)
この解釈には、「Refererにはリンク元のURIのみしか設定してはならない」という前提が定義されている必要がありますが、RFC2616にはそのように記述されていません。リンク元とは異なるRefererが送られることはあきらかにおかしい挙動である為、省略された可能性も高いですが、Must Notの挙動として定義されているかどうかは別の問題であるでしょう。

従って、Refererを使用したCSRF対策が、「Refererに任意の値を設定出来てはならない」という前提の上に成り立っているのならば、論拠としては薄いのではないでしょうか？
「こういう定義がされているから、この機能を実装してはならない」という論拠に比べ
「こういう使い方をされることがあるから、この機能を実装してはならない」という論拠に説得力を感じることは出来ません。

以下補足

おおいわさんは、クロスドメインでヘッダ操作が可能であることに問題の根本があると考えているように見受けられたのですが、高木さんとは意見が違うのでしょうか？

「セキュリティ上問題があるから、クロスドメインでヘッダ操作が出来てはならない」という前提の上に成り立っているのならば、納得がいくのですが・・・
ただし、この場合は、RFCに従った実装の上でセキュリティの問題が発生することを証明する必要があると思います。また、ヘッダ操作が可能なプラグインの開発者はセキュリティ上の問題が発生しないことを考察した技術文書を公開するなどの慎重な対応を取ったうえで、機能をリリースすべきであるとも思います。Flashは残念なことに、このような技術文書を公開していません。

追記 11/19
はてなブックマークで

例が挙げられていると例以外のケースを除外するというご都合思考。「obtained from」を無視している。

という、酷評を頂きました。
「obtained from」を無視している。が何を意味しているのか良く分からずに困っていたら

The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

のownをRequest-URIに結び付けているんじゃ？って友達に教えてもらいました。
そうすると、Request-URIが、それ自身のURI(それ自身=Request-URI)を持たない出所から得られたもの（例えばユーザのキーボード入力のような）である場合には、Refererフィールドは送信してはならない。という訳となって、リクエスト送信元のページにRequest-URIが書かれていなければならないことになり、高木さんの主張の意味が分かります。
でも、ownはsourceにかかっていて、Request-URIが、（例えばユーザのキーボード入力のような）それ自身のURI(それ自身=リクエストの出所)を持たないソースから得られた場合には、Refererフィールドを送信してはならない。
という訳が正しいのではないかなーと思います。
(http://example.com/test.swf がURIを持たないと言っている?の可能性がありそうな気もします)

また、例が挙げられていると例以外のケースを除外するというご都合思考。
とも書かれてしまいました。

このように、前例に照らして、同一ホスト以外に任意のヘッダを送ることは、それを許すような製品があればそれは脆弱性であるというコンセンサスが業界にあると判断した。

前例をあげるが実は大量に報告されている脆弱性レポートを無視した文書の構成は、ご都合主義ではないのか？という疑問があります。
http://secunia.com/search/?adv_search=1&s=1&search=Header&w=0&vuln_title=1&vuln_software_os=1&vuln_bodytext=1&vuln_cve=1&critical%5B%5D=0&impact%5B%5D=9&where%5B%5D=0
（前例としてあげられている脆弱性レポートも、Refererのくだりは「問題があるとは思えない。」という返事に終わっていたり^-^; )https://bugzilla.mozilla.org/show_bug.cgi?id=302263#c5

なんか、よく分かりません。