「Covert Redirect」についての John Bradley 氏の解説 - 訂正版

先ほどの翻訳記事の原文への @miyagawa 氏からの指摘を受けて John Bradley 氏が新たな記事「OAuth 2 and Fragment encoding.」を書かれているので、翻訳します。

おぅ、わいや、John や。

昨日はカリフォルニアで開催されてるID厨の祭典「Internet Identity Workshop」ちぅイベントで、IETF OAuth WG のメンバーが Open Redirector の問題について話し合ったで。

数年前 JavaScript クライアントを想定してレスポンスの fragment encoding を採用する際、わいらはその選択についてそらぁ連日朝まで語り合ったもんや。

レスポンスの fragment encoding を採用した理由はいくつかある:

1. JavaScript クライアントが token を取得するために、一度 server-side に token を送って、再びそれを JS クライアントに送り返すっちゅう無駄な round trip を避けれるっちゅうのが一個目の理由。
2. POST encoding みたいに fragment encoding やったら referrer を通じて token が漏れる心配が無いっちゅうんが2つめ。
3. で、3つめの理由が、fragment は server-side には渡らへんから、server がさらに redirect する際にその fragment を含めるっちゅうのを防止できるっちゅうやつや。

でもな、詳しくはこれから話すんやけどな、最初の2つは正しいんやが、最後の3つ目は全部のブラウザで正しいとは言えへんねや。

わいらが朝まで fragment encoding について語り明かしたあの日々から数年、ブラウザの挙動は変わってしもうた。いまやブラウザによっては、302 リダイレクトレスポンス受けたときに Location ヘッダーに指定される URL が fragment を含んでへん時は、リダイレクト元の URL に含まれてる fragment をそのまんまリダイレクト先まで引き回すようになったんや。

詳しくは、宮川はん (@miyagawa) がええ記事書いてくれてはる。わいもこれを受けてちゃんとチェックしたけど、これはめっちゃリアルや。

fragment encoding を採用した時の3つの理由の最後は、もはや成り立たへんねや。OAuth WG は仕様をアップデートして、この問題をちゃんと明確にせなあかん。

この問題が明らかになったことで、redirect_uri の exact matching の重要性が急上昇すんで。Developer はもはやそれを無視できへんはずや。OpenID Connect 仕様みたいに、OAuth 2.0 仕様でも exact matching の要件について明記されるんを期待しようやないか。

この問題自体は OAuth 仕様の問題やない。これはセキュリティドキュメントで詳細に定義するべき問題や。

このケースやと、ブラウザ側が変わってもうて、その変化がちょっと分かりづらかったもんやから、わいらが Developer にむけてそれを明確にする必要がでてきたってわけやな。

クライアントクレデンシャルを使う Code Flow は引き続き security 上のメリットがあるんやけど、もしクライアントが client secret を持てへんかったりブラウザ内で動作してる場合でも、登録済み redirect_uri との exact matching をしてるんやったらそのクライアントは引き続きセーフや。

わいらは OAuth 2.0 の Proof of Possession ちゅう拡張にも取り組んどるんやが、こいつはええで。これ使えば attacker が漏洩した access token を使うことすら防止できるっちゅうシロモンや。

John B.