RFC7231のリファラに関するメモ

gistfile1.txt

https://twitter.com/bulkneets/status/476343189717012480
をきっかけにリファラにabout:blankが提案された経緯について調べていた。

単にnull値として使えると定義されただけで、現状積極的に送れと推奨されているわけではないと認識している。
この変更で https://trac.tools.ietf.org/wg/httpbis/trac/changeset/2072
「about:blank送る or 全く送らない」と書かれていたのが「全く送らない or about:blank送る」と順番逆になったりしている。

----

RFC7231のリファラに関するメモ

- リファラが無いことを明示的に示すためにabout:blankを使うことが提案されている
- UAはリファラを on/off 出来るべき、という記述が無くなっている。
- https から http へのリファラ送信は MUST NOT に変わっている。
- fileやdataからのリファラ送信は明言されていないが「汎用的なUserAgentは送らない」とかかれてる
- 中間者(firewallやproxy)やブラウザ拡張機能は、same originに対するリファラを変更・削除すべきではない(SHOULD NOT)

で、about:blankについてはURL直接入力やブックマークからの遷移の際に使えると書いてあるだけで
file, data, ftp 等からの遷移についてどうすればいいのか明示的な指定はない。

----

リファラにabout:blankが使えるようになった経緯

Adamさんはどうしたかったのかと言うと。
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0155.html

"This would let servers distinguish between a header suppressed by the
attacker (value is null) and suppressed by the network (header is
gone) in the same way the Origin header proposes."

- 攻撃者によってリファラが取り除かれた → 「UserAgentによる削除」の場合、null値が送られる
- firewall製品による削除 → リファラヘッダがそもそも送られない

というのを想定していたようだ。攻撃者によってリファラが消されるようなケースでは"null"つまりabout:blankを送り
firewallによって削除されるようなケースはリファラが全く送られない、というのをサーバー側で区別できるようになる、と。

「空リファラを許容しているようなダメなCSRF対策をとっている」アプリがあったとして
デフォルト設定のままのリファラ送信するユーザーがabout:blankが送られるようになれば、
それは異なるリファラとして保護されるようになるだろう。(リファラを空にするユーザーは保護されない)
お前らが勝手にリファラ削除したことで被害を受けてもしったこっちゃねえよ、というスタンス。

で、firewallやブラウザ拡張に対しては「same originの場合にはリファラを変更・削除すべきではない」という勧告を出すことで
正常利用時にもエラーになるようなケースを抑止できる。空リファラ許容サイト + 攻撃受けた場合には保護されないけど。

----

Originのnull値については origin: nullがある。
例えばこういうdata uriを入力してフォームボタンを送ることで検証できる
>||
data:text/html,<form action="http://localhost" method=post><input type=submit>
||<

Chrome, Safari, Opera(Blink)ではOrigin: null というリクエストヘッダが送られる。

----

AdamさんはリファラをCSRF対策に使う際のメリット・デメリットについてきちんと把握していて
3%のユーザーが「リファラを送らない」とのこと。
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0053.html

で、null値送信を必須にすることで、Origin普及より早くCSRF対策が進むんじゃないか、という意図だったようだ。
ただ、https -> http のケースではヘッダを送らない、と書かれてしまったので
「攻撃者がリファラを削除」のケースはやはり、今後もリファラヘッダが全く送られないことになるだろう。
(Origin:nullは新規だから良いけど良いけど、about:blankに対応するUserAgentあるとは思えないし)

必須にしちゃうと既存UAが非準拠になってしまうし、何より空なのに必ず送れなんて、余計なヘッダ増えるだけだろ、という感じがする。
なので「送信しなくてもいいし」「about:blankでもいい」という中途半端な提案にとどまったし、about:blankが使えるように書かれているケースも限定的だ。

このRFC通りに実装すると、about:blankが送られるケースは限定的になるので
「ユーザーがブックマークしている可能性が高い」というヒントを与えることになってしまう。
ブラウザが積極的にサポートするとは思えない。
空のケースで常に送れというのも「about:blank」を正常に処理できない可能性を考慮すれば無いだろうな。
今までもbookmarkとか変なのを送るUAはあったっぽいけど。
「リファラが空であるべきケース」なのに余計なリファラがつくことによって逆にエラーになるとか。まああんまりなさそうだけど。

----

結局リファラは今後も「常に送られるわけではなく」(same originでは送るべきというふうに変わったけど)
削除される可能性があると考えなくてはいけない。ただし今後、same originのリファラを必須にしても
「新しいRFCではsame originのリファラは削除すべきではないって書いてあんだろ、これでいいんだよ」
という風に言える状況にはなったんじゃなかろうか。
UserAgentはリファラをオン・オフできるべき、という記述も無くなってしまっている。

same originだったらリファラ送ってもプライバシー上の懸念がないかと言うと、そうは思わない。
同一origin内でも別ユーザーが管理しているケースもあるし(ブログとかgeocitiesとか)、
リファラを送信することで信用出来ない第三者のアクセス解析に収集されることを好まないユーザーもいるだろう。

----
ブラウザがいくつかのケースでabout:blankを送信するようにすることでセキュリティ向上に繋がるかというと

- リファラ空弾く厳格な対策してるサイト → 影響なし
- 空リファラ許容CSRF対策のサイト → 攻撃者はリファラ完全削除されるhttps->http使って依然として攻撃可能

ということになってしまうので、CSRF対策としては意味ないことになる。origin:null相当が欲しいという当初の目的は全く果たせていない!!

というか取り敢えずnull値定義だけしておくかー、ぐらいのノリで実際にどういう影響があるのかについては途中で考えるのが面倒くさくなったのではないかと思われる。

----

まあ、こんなかんじでリファラに about:blankとかいう、いかにも使い道なさそうな微妙なものが残ったけど
少なくともsame originに関してはリファラ消すな、いじるな、というのがCSRF対策的には大きな変更なんじゃないかな。
というかまあこういう数人の議論で、使い道のよく分からんものが提示されたり、リファラ必須にしようとか言い出したり、
そういうのが決まるんだなーと思うと、積極的に意見を発信していかないとイカンなあと思うと同時に関わりたくないとも思う。