事務局メンバーによる、OpenID関連のあれやこれや
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。
追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。
Covert Redirect and its real impact on OAuth and OpenID Connect を、とりいそぎ訳しました。ご参考まで。
博士課程の学生である Wang Jing 氏が「リライング・パーティ内のオープン・リダイレクター」を見つけて、今朝公表してたけど、これを CNet や他のメディアがネタにしたせいで、わたしは朝のワークアウトを中断しなくちゃいけなくなって、今日一日ぶち壊しになっちゃったよ。
Heartbleed は実際の話だし相当な問題に違いなくて、まだまだやらなくてはいけないことがたくさん残ってると思う。それにひきかえ、オープン・リダイレクターについてはかなり昔から問題視されてて、SAML にしても OAuth2 にしても OpenID Connect にしても緩和策があるんだよね。
OAuth 2.0 だったら、脅威モデルおよびセキュリティに関する考察 (RFC6819) の Sec 4.2.4 に書いてあるよ。要は、攻撃者が自由に redirect_uri を指定できるようにすることがトラブルを招くってこと。OpenID Connect では、規約上、redirect_url の事前登録を必須にしてる。またマッチングについては explicit に行わないといけない (Sec 3.2.2.1)。
This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). When using this flow, the Redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http: scheme withlocalhost as the hostname.
OAuth と OpenID Connect には複数の response_type があるんだけど、さきのリポートの著者は、最も一般的な response_type が "code" であることに触れず、またクライアント・クレデンシャルを使ってもう一度呼び出しを行わないとアクセス・トークンは手に入らないってことも無視してる。つまり、たしかに "code" がオープン・リダイレクターを経由して漏洩するかもしれない、という点については彼が正しい。けど、その code を使って攻撃者がなにかできるわけではないよ。これこそまさに、"code" response_type を使うことで得られる効果的な緩和策だね。
response_type にはこの他、ブラウザー内にて実行される JavaScript クライアント向けに設計されたものもあって、著者はリポートで挙げてる Facebook の例で使っている。このフローでは、認可サーバーが直接アクセス・トークンを、URI フラグメントに入れて、登録されている redirect_uri に返却する。
フラグメントは redirect_uri に示されているサーバーには渡らないから、ブラウザー内にて、そのドメインから読み込まれた JavaScript によって、"location.hash" プロパティ経由で抽出しないといけない。まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。
「こうやって ESPN のサイト経由で Facebok 攻撃できるよ」と謳ってるビデオを観たけど、(攻撃に関して説明している) サイトの情報も、このビデオの内容も、理解するのはちょっと大変...。
間違いなく言えることは、ESPN にはオープン・リダイレクターがあって、このリダイレクターはかなりまずい。渡された URI のパラメーターをターゲット URI にコピーするよう仕向けることができちゃう。
Facebook は OAuth2 に似てるけど、「セキュリティに関する考察」仕様の多くを無視して (話を聞いてよ...)、開発者の利便性を優先してる。Facebook は登録されている redirect_uri のドメイン部分しか検証していないので、任意のサブドメインやパスを追加することができてしまう (ちなみにほとんど知られていないことだけど、Facebook の中の人は Facebook.com 配下のすべてをホワイトリストに載せてたときには、興味深いすべての攻撃が可能になってた)。 このせいで、攻撃者が ESPN のオープン・リダイレクターを使えてしまうんだ。
この点については、著者は完全に正しい。けど奇妙なのは、著者が使っているブラウザーが、URI フラグメントをリダイレクターに送信しているように見えるところ。これって、ブラウザーが改竄されていない限り不可能だよ。
ブラウザのフラグメント処理を乱す攻撃については、これまでも存在してきたし、そして Facebook や他社は、フラグメント処理の無効化をさせないための緩和策を既に実施してる。
わたしが見た限り、そのビデオにて示されている攻撃では、ユーザーが自分でアクセス・トークンを抽出してる。ブラウザーのバーから URL をカット & ペーストして。つまり、インプリシット・フローであれば、ユーザーが自分自身を攻撃することは可能だよ。けどそれを「深刻な脅威」とみなさないよね。
OpenID Connect ではさらに OAuth を上回るセキュリティ対策として、クライアントが署名つきリクエストを送れるようになってる。これによりリクエスト・フォージェリーを防ぎ、レスポンスを暗号化することが可能だ。
今回のリポートに新しい話は見当たらないなあ。良く知られている攻撃手法だし、みんな (もしかしたら Facebook を除くかもだけど) 緩和策を講じてる。
フラグメント処理の無効化を利用した Facebook への攻撃手法、そして Facebook が取った対策については、もっと良い分析をしてる人がいるよ。Untitled Blog の 2012 年の投稿。
今回のリポートが人々を興奮させることができて、きっと Wang Jing 氏は有名人気分を味わっているだろうね。でもこのリポートにある攻撃の「新規性」については、わたしは credit をあげられませんぞ。
Regards
John B.
@ve7jtb