【クラウドID管理解説】
権限認可オープンスタンダード「 OAuth 」—メリット+脆弱性課題
「脆弱性課題」として、「脆弱性の主な原因」+「脆弱性要素①：OAuthクライアントアプリケーション」「②：認証コードとアクセストークンの漏洩」「③：欠陥のあるスコープ検証」について参照できます。
コンテンツ
「OAuth」とは
「OAuth (Open Authorization) 」とは、広く利用されている権限認可オープンスタンダード(プロトコル)です。
Webサイト(Webアプリケーション)がIDサービスプロバイダ(Google、Facebookなど)に対してユーザーアカウントの制限付きアクセスを要求できるようにすることで、ユーザーはログイン資格情報を対象アプリケーションに公開せずにアクセスできます。
OAuthの「メリット」
シングルサインオン
OAuthを利用することにより、さまざまなアプリケーションでシングルサインオンが可能となるため、個々のアプリケーション単位で「ID+パスワード」を管理する必要がなくなります。
IDサービスプロバイダ(Google、Facebookなど)で登録している1つのパスワードのみを管理するだけでよくなるため、ユーザーエクスペリエンスが向上します。
独自認証システムを実装する必要がない
OAuthを使用すると、アプリケーションはIDサービスプロバイダに対してユーザー認証を実施できます。
そのため、アプリケーション内に独自の認証システムを実装する必要がなくなります。
実装が簡単
OAuthでは、情報(アクセストークン)の送受信に「HTTPプロトコルのみを使用」します。
特殊で複雑なプロトコルを使用する必要がないため、簡単にサービスおよびクライアントを実装できます。
パスワードが送受信されない
ユーザーがアプリケーションにログインする時に、ユーザーパスワードはアプリケーション側に伝達されない仕組みであるため、パスワード情報を直接やり取りする仕組みと比較して、セキュリティを向上させることができます。
エンタープライズ企業の信頼性
OAuthログインをサポートするアプリケーションは、「Googleでログイン」や「Facebookでログイン」などのオプションを指定してユーザーに認証を求めます。
ユーザーのID情報管理は「Google」や「Facebook」などのエンタープライズ企業に委託することになります。
この仕組みにより、ユーザーは信頼性が低い新興企業などに対してID情報を直接共有せずに利用できるメリットがあります。
OAuthの「脆弱性課題」
脆弱性の主な原因
仕様が比較的あいまい
OAuthは「柔軟な仕様」となっています。
裏を返せば「比較的あいまいな仕様」でもあるため、脆弱性が発生しやすい一因となっています。
・ユーザーのデータを安全に保つためには多くの構成設定が必要
・実装の大部分はオプション
・設定によっては機密性の高いデータもブラウザを介して送信されてしまう可能性がある
・構成設定によっては非常に脆弱なシステムが構築されてしまう
セキュリティ対策実装は開発者に依存
OAuthには「組み込みセキュリティ機能が十分ではない」という課題もあります。
そのため、構築されるシステムのセキュリティレベルは実装する開発者に大きく依存してしまいます。
・構成オプションの適切な組み合わせ
・堅牢な入力検証
・独自の追加セキュリティ対策 など
強固なセキュリティを維持するOAuthシステムを独自構築するためには、熟練したスキルレベルが必要となるため、不慣れな開発者が担当すると脆弱なシステムができあがってしまうリスクが大きくなります。
脆弱性要素①：OAuthクライアントアプリケーション
暗黙的許可タイプの不適切実装
「暗黙的許可タイプ」は比較的単純であるため、「シングルページアプリケーション」や「クライアントサーバ型Webアプリケーション」でもよく使用されます。
このPOSTリクエストはブラウザを介して攻撃者に公開されます。
クライアントアプリケーション側において、アクセストークンがリクエスト内の他データと一致することを適切にチェックしない場合、この動作は深刻な脆弱性につながる可能性があります。
stateパラメータの使用に失敗
アプリケーションが「stateパラメータ」の取り扱いに失敗すると、攻撃者は「クライアントアプリケーションの被害者ユーザーのアカウント」を自分のアカウントにバインドできてしまうことで、乗っ取り被害が発生します。
脆弱性要素②：「認証コード」と「アクセストークン」の漏洩
OAuthサービス自体の構成が不完全な場合、「認証コードを盗まれる」や「他ユーザーのアカウントに関連付けられたトークンへアクセス」などの事態が発生し、アカウントが完全に危険にさらされてしまう可能性があります。
脆弱性要素③：欠陥のあるスコープ検証
OAuthフローでは、「承認リクエストで定義されたスコープ」に基づいて、リクエストされたアクセスを承認する必要があります。
しかし、OAuthサービスのスコープ検証に欠陥があった場合、「攻撃者が取得したアクセストークン」について「追加アクセス許可でアップグレードしてしまう」可能性があります。
「OAuth2.0」におけるベストプラクティスガイドライン
OAuthプロトコルの実装フェーズにおける抜け穴の存在は、ユーザーデータを収集している企業にかなりの損失をもたらす可能性があります。
企業の顧客と従業員に最大限の安全性を確保するためには「実装ミス回避」が重要です。
すべての通信にSSLを使用
SSLの有効化
SSL(Secure Sockets Layer)は、Webサイトの防衛線として、「データ侵害」「フィッシング詐欺」「その他の脅威」を防ぐために役立つ仕組みです。
リソース管理者がSSLを有効化していない場合、『サイバー犯罪者は、数分で、基本的なセキュリティをバイパスしてユーザーデータに侵入できる』とされています。
SSLを使用していないOAuthセキュリティは、「ユーザーの機密情報を攻撃者に明け渡している状態」となります。
SSL証明書チェック
SSLセキュリティが有効になっていることを確認することで、Webサイト(Webアプリ)を攻撃者から保護できます。
Webブラウザは、「SSL証明書がない場合」もしくは「有効期限が切れている場合」に警告します。
モバイルアプリケーションでは、Webサイトが適切なSSL証明書で十分に保護されていることを確認する必要があります。
データ暗号化
企業が繰り返す最大の過ちの1つとして「重要なデータを暗号化せずにプレーンテキストで保存してしまう」ケースがあります。
パスワード暗号化
認証が完全にパスワードに依存している場合、攻撃者がユーザーデータやビジネスデータにアクセスできないように、パスワード情報を暗号化して厳格に管理する必要があります。
データ暗号化+SSLを提供するCIAMソリューションを使用することは、ユーザーのWebサイト(Webアプリ)ログインにおいて最高のセキュリティを実現するための最良のオプションとなります。
ハードコーディングの禁止
「シングルページアプリケーション」や「モバイルアプリケーション」などのソースコードに、「ハードコーディングされたクライアントシークレット文字列」が含まれていないことを確認する必要があります。
攻撃者にクライアントシークレット文字列を悪用されてしまうと、認証サーバーにアクセストークンの発行を要求するために、クライアントアプリケーションを偽装されてしまいます。
また、更新トークンと認証コードを再生するためにも使用されてしまいます。
トークン
ログイン用アクセストークン
企業はセキュリティを最大化するために、「ログイン用アクセストークンが長期間アクティブにならないように短時間に設定する」必要があります。
決済関係などの重要な情報を扱うアプリケーションの場合、「アクセストークンの有効期間は60秒を超えないようにする設定しておく」ことで、セキュリティを向上できます。
更新トークン
更新トークンは、サイバースペースの全体的な安全性を向上させる上で重要な役割を果たします。
Webサイトのユーザーがしばらくアイドル状態の場合、セッションを自動的に終了させます。
ユーザーが再度アクセスする場合には、資格情報をもう一度入力せずに、事前定義された時間のみ、再びアクセスを提供できます。
この仕組みにより、前のセッションがすでに期限切れになっているため、最終的にセキュリティ違反のリスクを減少させることができます。
トークン漏洩リスク
「盗聴やアクセスコード漏洩が発生する可能性があるのかどうか？」をチェックするために、承認サーバーがHTTPSではなくHTTP経由で「auth_code」値を返すかどうかを確認します。
また、認証コードは「リファラーヘッダ」「Webサーバーログ」「プロキシログ」「オープンリダイレクト」「ブラウザ履歴」などを介して漏洩する可能性もあります。
リダイレクトURI
URI設定
承認サーバーは、「クライアントリダイレクトURI」および「事前登録されたURI」と一致する必要があります。
この対策は、認証コード(アクセストークン)の漏洩を防ぐために役立ちます。
リダイレクト設定
クライアントは「クエリパラメータ(ユーザー制御)から取得したURI」にユーザーを転送しないようにする必要があります。
攻撃者は、認証サーバーをだまして攻撃者が制御するWebサイトに認証コードを送信させるために、許可付与要求でREDIRECT_URIパラメータを操作し、受け入れられないはずのURIを入力します。
適切に対策しておくことにより、攻撃者が認証コードを盗み出し、トークンにアクセスするために使用される可能性を低減できます。
この種のリダイレクトが必要な場合、クライアントはオープンリダイレクトに対して適切な対策を講じる必要があります。
検証方法
アプリケーションが認証コードを使用してユーザーをリダイレクトする場合は、「REDIRECT_URIパラメータにさまざまな値を入力して受け入れられるかどうか？」を検証します。
日本企業向けクラウドID管理サービス「Keyspider」とは？
Keyspiderオフィシャルサイトでは、Keyspiderに関する情報を紹介しています。
「日本企業向けである理由」「Keyspiderが必要である理由」「JSOX法対応」「業務自動化」などについて参照できます。
参考サイト