OpenIDにかんするさまざまな疑問を解消していく本連載。今回は、RPからOPに対して認証アサーションリクエストが行われる過程で抑えておきたいポイントについて解説しましょう。
OpenID Provider(OP)が悪意のあるRelying Party(RP)から不正なリダイレクタを介したリクエストを受け付けた場合、どのように検証すべきでしょうか。
国内でもOPが多数登場してきたこともあり、OpenIDを利用できる場面が増えてきました。OpenIDの情報がまだ不足しているためか、セキュリティ面などで抑えておきたいポイントがまだ周知なものとはなっていないように感じています。本稿では、RPからOPに対して認証アサーションリクエストが行われる過程で抑えておきたいポイントについて解説しましょう。
OpenID Authentication 2.0の「9.1. Request Parameters - OpenID Authentication 2.0 Final」に書かれていますが、RPが認証アサーション要求をする際には、通常、「realm」「return_to」という値を指定します。
例えばitmedia.co.jpがRPの場合、次のような指定をすることでOPに認証アサーションリクエストを行うことになります。
realm
http://*.itmedia.co.jp
return_to
http://www.itmedia.co.jp/example/handler
return_toとはUser Agentを介した間接通信において、レスポンスを受け付けるためのURLをRPがOPに事前に通知しておくためのものです。一方、realmはこのreturn_to URLのマッチパターンをワイルドカードを用いて指定します。realmに反したreturn_toに対してOPがUser Agentに対してリダイレクトを行ってしまうと、中間者攻撃が成立する可能性があります。
どういうことかといえば、RPがOPに対して認証アサーションリクエストを行う際に、realmと矛盾しないリダイレクタをreturn_to URLとして指定し、そのリダイレクタで認証セッションを奪ってしまえば、第三者がなりすましを行うことができてしまうのです。
またrealmに矛盾しないreturn_to URLであっても、RPとはまったく関係のないURLにリダイレクトされるケースも考えられ、ただこれをうのみにして良いかどうかという話もあります。
realmと矛盾しないreturn_toは簡単に思い浮かべることができます。筆者のブログで幾つか例示するとともに、国内OPの対応状況をまとめています。こちらを参照するとすぐにイメージがつかめるかと思いますが、いずれにせよ、悪意のあるRPだったとすれば中間者攻撃が成立し得る素地が存在していることはご理解いただけると思います。
では、RPからの認証アサーション要求は、どのように検証すべきでしょう。筆者は少なくとも以下の2点は抑えておきべきであると考えます。
前者はpublic suffix projectが信用できるならば解決策もありますが、一営利団体が安全ではない方法で収集しているデータベースですので、うかつに(使う|信頼する)わけにもいきません。現実解としては、少なくともrealmにマッチするかどうかと、そのrealmの形式が後者のようなものでないという点を検証しなければならないでしょう。
また、checkid_setupモードの場合は、ユーザーに認証レスポンスをRPに返すかどうかを問い合わせる画面を出すのが一般的ですが、完全なreturn_to URLでユーザーが不正なURLであると判断できるケースもあるので、存在する場合は必ずrealm、return_toの両方を明示するようにしましょう。
サイボウズ・ラボで研究開発にいそしむPerlハッカー。Perlを中心とした開発のノウハウやネタをShibuya Perl Mongersのイベントで発表するなど講演活動も行う。最近ではOpenIDの実装方法や考察などをブログ「Yet Another Hackadelic」などで書き連ねている。山口氏へのコンタクトはこちらから。
Copyright © ITmedia, Inc. All Rights Reserved.