OpenIDをとりまくセキュリティ上の脅威とその対策：OpenIDの仕様と技術（4）（2/3 ページ）

[山口徹，サイボウズ・ラボ株式会社]

OpenIDセキュリティのいま

　通信経路のセキュリティに関して学んだ後は、実際にどのような攻撃や脅威が存在するかいくつかの例について学び、それらへの対策について考えてみましょう。なお事前に断っておきますが、この後説明する問題に対する回答は完ぺきだとは保証できません。想定されるケースや対処法に関してはコミュニティの方で議論があるので、詳しくはOpenID Wikiのセキュリティページを見てください。

OpenIDでも考えなくてはならないフィッシングの脅威

　まずは典型的なセキュリティ上の脅威であるフィッシングですが、OpenIDの場合はどのようなシナリオとなるかを説明します。

1. 悪意のあるConsumerサイトに行くとOpenIDでのログインを模したフォームが存在する
2. ユーザーはそのログインフォームに自分のIdentifier URLを入力する
3. 悪意のあるConsumerはユーザーのIdPによく似たニセのIdPにリダイレクトさせる
4. ニセのIdPはユーザーにユーザー名とパスワードを求める
5. ユーザーがいつものIdPとの違いに気付かず認証情報を入力する
6. ニセのIdPはユーザーのアカウント情報を入手できる

という流れで悪質なConsumerがユーザーの認証情報を取得するというシナリオが典型的です。

図3　OpenIDサイトでのフィッシングの例

　これを防ぐには、VeriSignが提供しているFirefoxの拡張であるOpenID SeatBeltなど、事前にOpenIDでのログインに確認を求めるような機能が必要です。これをユーザーがインストールしていれば、悪意のあるConsumerのログインフォームがフィッシングであるということを警告してくれる場合があります。

　あるいはIdP側で認証ページにユーザーごとのユニークな情報（色や画像など）を載せることによって、悪意のあるConsumerにニセのIdPを作りにくくさせることも有効な対策だと思います。

　どうしてこのようなフィッシングが成り立ってしまうかといえば、事前にConsumerとIdPの間に信頼関係がないのが最も大きな理由といえると思います。

OpenID Realm Spoofingに気をつけよ

　より狡猾なフィッシングも存在します。それはOpenID Realm Spoofingと呼ばれる手法です。この手法が存在するケースは次の条件が満たされた場合です。

• 一般的には信頼されているConsumerサイトである
• そのConsumerサイトではオープンなリダイレクタ（転送専用のURL）が存在する
• そのConsumerサイトをエンドユーザーがOpenIDを利用して使っている

　OpenIDでの認証にはrealm（認証の有効範囲指定）としてtrust_rootという設定項目を使います。

　悪意のあるConsumerサイトと気付かずユーザーがOpenIDでログインしようとした際に、悪意のあるConsumerサイトは一般的に信頼されているConsumerサイトをtrust_rootとし、return_toにはその信頼されているConsumerのリダイレクタに悪質なConsumerのURLを記載した値を指定することによって、認証画面では信頼されているConsumerサイトに対して認証データを送るような画面が出てくるでしょう。

　この状況は何がまずいのかといえば、Simple Registration ExtensionやAttribute Exchangeといったプロフィール交換機能を用いた場合に、ユーザーの個人情報が悪意のあるConsumerサイトに盗まれてしまうということです。

図4　OpenID Realm Spoofingの流れ

　IdP側では認証画面でユーザーに対して、

• どのConsumerからのリクエストか
• trust_rootやreturn_toがどこに対してか

を明示し、またConsumerのURLとtrust_root、return_toのドメイン名が異なる場合は警告を出すなどの対策をすべきでしょう。

アカウント名はバレバレ？ OpenIDとパスワードの関係

　次にOpenIDのIdPでのユーザーのアカウント情報とパスワードに関して考えてみましょう。そもそもログインという手続きはIDとパスワードの入力を求めるケースがほとんどで、OpenIDの場合はこのIDの部分がURLとなります。このURLは現実に存在するページでIdPの場合は特定のパターン化された文字列でしょう。

　URL文字列の例を挙げれば、

• http://claimid.com/[username]
• http://[username].myopenid.com/

のような形です。

　さて次のような検索を実行してみましょう。

• Googleで「"Identity Page for" site:*.myopenid.com」を検索

　お分かりでしょうか。myopenid.comを例に取りましたが、Google検索を用いてアカウント名の収集が可能です。似たようなやり方で、恐らくほかのIdPのアカウント名の収集も可能でしょう。

　このIDに当たるURLに恐らくIdPでのローカルアカウント名が含まれているケースがほとんどで、このローカルアカウント名とパスワードで認証するIdPが多いことから、後はパスワードさえ分かればアカウントのクラックが成立してしまいます。

　仕組み上、Identifier URLをアクセス不可にしてしまうのは出来ませんが、少なくとも検索エンジンに収集させない手続きは必要でしょう。検索エンジンを制御する場合はrobots.txtを適切に記述する必要があります。

UserAgent: *
Disallow: /

のような記述をIdPのページ構造に合わせてDocumentRootにrobots.txtとして配置しておけばよいでしょう。あるいはhtmlのmeta要素を使って、ユーザーのIdentifier URLごとに

<meta name="robots"  content="noindex,nofollow" />

のように記載しておくのもよいでしょう。詳しくはThe Web Robots Pagesなどの資料を見て設定してください。

　当然、これは収集しにくくするためのちょっとした工夫で、対策として万全ではありません。より高いセキュリティを確保したいならば、そもそもエンドユーザーのパスワードに安易な文字列を用いさせないことと、辞書アタックのような分かりやすい攻撃を即座にシャットアウトするような仕組みが必要だと思います。

　前者はCPANのライブラリだとData::Passwordモジュールや、Data::Password::Checkモジュールなどを使うと、パスワードの検証および強度のチェックを行うことができます。使い方に関してはそれぞれのモジュールのオンラインドキュメントを見てください。

　パスワードの強度に関しては、

• JOEパスワードを許可しない（JOEパスワードとはusername = passwordの形式のこと）
• 自分のアカウント名に近いパスワードを許可しない（PerlだとString::Trigramモジュールで文字列同士の類似度を算出できるので、この類似度に対して一定のしきい値を設ける）
• 辞書アタックでヒットしてしまうようなパスワードを許可しない

といった対策を行えば、攻撃者が簡単にパスワードクラックを行うことができないパスワードをユーザーに強制することができるでしょう。

【関連記事】

セキュリティ対策の「ある視点」（2）

ディレクトリ非表示の意味をもう一度見つめ直す

http://www.atmarkit.co.jp/fsecurity/rensai/view02/view01.html

　また後者の辞書アタック対策はOpenID独自のセキュリティ対策ではありませんが、基本的な方針として認証手続きの失敗が特定の時間内に指定した回数以上失敗した場合、アカウントを凍結するといったやり方が基本的な対策方針となると思います。