OAuth 2.0 では state パラメータってのがあって、それをちゃんと使わないと CSRF 脆弱性ができちゃうよって話は、@ritou 先生のスライドなどでみなさん勉強したんではないでしょうか。state パラメータは RFC 6749 では RECOMMENDED 扱いで、REQUIRED ではありませんが、OAuth 2.0 をログインに使う場合は REQUIRED にすべきでしょう。OAuth 2.0 をログインに使うの、Token 置換攻撃とか Covert Redirect + Code 置換攻撃とか、いろんな罠がありますねぇ〜。
OAuth 1.0 ならそんなことないのに…
そう思ってた時期が、僕にもありました。
でも @ritou 先生よく言ってるじゃないですか。「Twitter の OAuth 実装クソや」って。でね、ほんとにクソやったんすよ、コレが。
Read on →昨日のCovert Redirect で Query 漏れるケースもある!?やOAuth 2.0 の脆弱性 (!?) “Covert Redirect” とはにあるように、OAuth 2.0 の code が漏れちゃうことも、ありえます。
漏れないためにやるべきことは、上記の記事やFacebook Login で Covert Redirect を防止するなんかでも紹介してるので、そちら読んでください。
で、今回の内容は「code が漏れたら何がまずいのか」についてです。
「Covert Redirect」についての John Bradley 氏の解説（追記あり）にも、こうありましたね。
OAuth と OpenID Connect には複数の response_type があるんだけど、さきのリポートの著者は、最も一般的な response_type が “code” であることに触れず、またクライアント・クレデンシャルを使ってもう一度呼び出しを行わないとアクセス・トークンは手に入らないってことも無視してる。つまり、たしかに “code” がオープン・リダイレクターを経由して漏洩するかもしれない、という点については彼が正しい。けど、その code を使って攻撃者がなにかできるわけではないよ。これこそまさに、”code” response_type を使うことで得られる効果的な緩和策だね。
あれ？code 漏れても問題なさそうですね？
ほんとでしょうか？
本当です。みんながちゃんと OAuth の仕様に沿って実装していれば。仕様に沿って実装してない場合は知らん。ちゃんとやれ。
本当です。Client がちゃんと client secret を漏洩させずに、OAuth の仕様に沿って実装していれば。client secret 漏らしたり仕様に沿って実装してない場合は、うちのユーザーに迷惑かかるかもしれんし、あなたのアプリ停止しちゃうね。
え？俺ちゃんと仕様に沿って実装できてんの？ …まぁ動いてるしできてる、よね！？ それに万が一 code 漏れても、うちに被害及ぶってより OAuth Server に被害及ぶはずやし、OAuth Server がちゃんと対策してれば、まぁなんとかなるよね？
ゆとりか！(｀ヘ´#)
OAuth Client 実装者がこういう考えだと、一瞬でやられちゃいそうですねぇ。
ってことで、ここでは「code が漏れたら OAuth Client 側でアカウント乗っ取りが発生する」ケースについて考えてみましょう。
Read on →Covert Redirect 連載最後は、location.href とか <meta http-equiv=“Refresh”> とかだと referrer 通じて query に含まれる code とかも漏れるかもね！ってお話です。
古いサイトですが、こことか見れば大体いいんじゃないでしょうか => リファラ実験
で、こういうリダイレクトをしてる箇所が OAuth 2.0 の redirect_uri なり OpenID 2.0 の return_to なりに指定されていれば、query に付いた code なり email なりがリファラ経由で外部に漏れるよね、という。
はい、漏れますね！ (投げやり
さて、そんなに該当例多くはないと思うのですが、ここまで該当してしまったサービスは、どうしますかねぇ…
Facebook であれば、Facebook Login で Covert Redirect を防止するにあるような方法で回避できますが、それ以外の OAuth Provider なり OpenID 2.0 Provider と連携してる場合は、困っちゃいますねぇ…
Read on →OAuth 2.0 Implicit Flow では Covert Redirect 経由で access token が漏れる件については既に紹介しましたが、ここではみなさん大好き Facebook Login で OAuth Client Developer ができる対策について紹介することにします。
以上、巧いフィッシング方法さえ思いつけば簡単ですね。
防御方法は、大きく分けて3つあります。
さて、OAuth 2.0 & OpenID Connect における Covert Redirect の問題 についてはまとめたので、次は OpenID 2.0 についてです。
いいですか、OpenID Connect ではなく、OpenID 2.0 ですよ。古い方です。懐かしいですね、OpenID Authentication 2.0 – Final。
そういえば、OpenID Foundation Japan の翻訳 WG を立ち上げて、一番最初に翻訳したのが OpenID Authentication 2.0 の 日本語訳でしたね…(遠い目
と、昔話はそれくらいにして、本題に入りましょう。
OpenID 2.0 では、レスポンスパラメータは query に引っ付いてきます。fragment は使いません。
なので、open redirector のリダイレクト先には、通常はレスポンスパラメータは渡りません。
全ての query パラメータをリダイレクト先に引き継いでしまうという、奇妙な open redirector を用意してる場合にのみレスポンスパラメータが外部に漏洩します。
まずはこの時点でそんなに心配することはなさそうですね。
まぁでもせっかくなんで、話続けますね。
Read on →