FacebookのoAuthでアクセストークンの発行元アプリを取得する方法


開発者ちゃん「認証にoAuth認証を使ってやったぜ~。ワイルドだろ~。」

ワ、ワイルドすぎます。。。

と、流行りの話題には流行りのギャグということで、
「openid」と「oAuth」を混同する理由の一つに、
“oAuth認証”という言葉が蔓延しているからではないかと思うきょうこの頃。

ので、いっそ”oAuth接続”とか呼んじゃえばいいのに。
openid認証 / oAuth接続、だったら、認証 / 認可、の対比が割と分かりやすい気がするし、
「接続」って表現だったら、「openid connect」もoAuth 2.0ベースというのが理解しやすいじゃん。

“oAuth認証”とか言っちゃうから何も考えず、oAuthをログイン時の認証に使っちゃう人がいるんですよ!
色んな偉い人が各所でセキュリティ上の観点から、認証にはoAuthではなくopenidを利用しましょうと言っていますが、
それでも、oAuthで認証を使っているアプリケーションがある程度存在しているのが現状だと思います。

というわけで、oAuth2.0(Implict Flow)を認証に用いた時の2つの対策を簡単にまとめておきます。
(openid connectは使わないので、Facebook限定の方法です)

【対策1:stateパラメータを利用する】
まぁ、これはFacebookの公式でも記載されているのでささっと書きますが、
いわゆる、CSRF対策です。

Facebookへリクエストする際に、適当なセッション情報を生成し、
そのセッション情報をstateパラメータとして送って、
コールバックされたstateパラメータとセッション情報の整合性を確かめるって感じです。

ペーペーの僕が説明するより、Facebook公式のソースをみたほうがよいです!
http://developers.facebook.com/docs/authentication/server-side/

はっきり言って、これをやっていないアプリケーションはワイルドすぎます。

【対策2:アクセストークンの発行元アプリ情報を取得する】

本題はこちら。
上記のCSRF対策やXSS対策をしても、以下のケースで攻撃可能です。

登場人物:
・oAuth2.0対応のソーシャルプラットフォーム(以下、ITOBOOK)
・ITOBOOKでアプリX(以下、ブラックアプリ)を提供しているふりをしている悪人X
・ITOBOOKで最近リリースされたアプリA(以下、ワイルドアプリ)
・ITOBOOKを使っているエンドユーザ(以下、いとうちゃん)

シナリオ:
・いとうちゃんがブラックアプリに登録 (ブラックアプリのアクセストークン発行)
・悪人XがワイルドアプリにアクセスしてoAutn認証フロー開始
・悪人XがITOBOOKからワイルドアプリへのコールバックを中断させる
・悪人Xがコールバックのレスポンスから取得できるアクセストークンをブラックアプリのDBから持ってきたいとうちゃんのアクセストークンに置き換え
・ワイルドアプリは受け取ったアクセストークンをもとに、悪人Xをいとうちゃんとして認証
・悪人Xがいとうちゃんとしてワイルドアプリを利用する

ね、ワイルドでしょ~。

というわけで、CSRF対策をしても、アクセストークンの置き換えは可能なのです。
で、これにどう対応するかというとopenid connectを利用するなど方法はいくつかあると思いますが、
Facebookではアクセストークンの発行元アプリを取得エンドポイントがありますので、今回はそれを利用します。

上記のシナリオで言うと、アクセストークンを受け取ったタイミングで、
発行元アプリのチェックを行い、ワイルドアプリ以外(今回はブラックアプリ)の場合は、
認証を通さないというフローにすれば、自分のアプリが発行したアクセストークンのみを認証することが出来ます。

ざくっと書くとこんな感じです。

// アクセストークン発行元チェック
$check_url = “https://graph.facebook.com/app?access_token=” . “受け取ったアクセストークン”;
$app = json_decode(file_get_contents($check_url), true);

if ($app['id'] != “自分のアプリID”) {
   echo(“アクセストークンエラー”);
   exit;
}

https://graph.facebook.com/app?access_token=”受け取ったアクセストークン”

で発行元アプリの情報がとれます。

oAuthやopenidは便利でライブラリも多いので、比較的簡単に実装出来ちゃいますが、
ちゃんと仕組みを知っておかないとあっという間にワイルドなシステムが出来てしまうので、
僕ももっと勉強しなきゃなぁ~。

参考URL:
「OAuth 2.0 (Implicit Flow) でログイン」の被害例
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam Protection by WP-SpamFree