|
最終改訂日 (yy/mm/dd):2015/09/04
はじめに
Security Assertion Markup Language 言語 (SAML) は、認可および認証情報を交換するためのオープンスタンダードです。リダイレクト / POST バインディングを使用した Web ブラウザーの SAML / SSO プロファイルは、最も一般的な SSO 実装の 1 つです。このチートシートでは、主に、そのプロファイルに焦点を合わせます。
メッセージの機密性と完全性の検証
- TLS 1.2 は、メッセージの機密性と完全性を保証する、最も一般的なソリューションです。追加情報については、SAML のセキュリティに関するドキュメント (セクション 4) を参照してください。この手順は、次に示す攻撃への対策に役立ちます。
- Eavesdropping (盗聴) 7.1.1.1
- Theft of User Authentication Information (ユーザーの認証情報の窃取) 7.1.1.2
- Theft of the Bearer Token (ベアラートークンの窃取) 7.1.1.3
- Message Deletion (メッセージの削除) 7.1.1.6
- Message Modification (メッセージの変更) 7.1.1.7
- Man-in-the-middle (中間者) 7.1.1.8
- メッセージにデジタル署名することは、メッセージの完全性と認証を保証する、最も一般的なソリューションです。追加情報については、SAML のセキュリティに関するドキュメント (セクション 4) を参照してください。この手順は、次に示す攻撃への対策に役立ちます。
- Man-in-the-middle (中間者) 6.4.2
- Forged Assertion (偽造アサーション) 6.4.3
プロトコルの使用の検証
これはセキュリティギャップの共通領域になります。実例については、Google SSO 脆弱性に関するドキュメント (AVANTSSAR 2008) を参照してください。その SSO プロファイルには、悪意のある SP (サービスプロバイダー) からの中間者攻撃に対する脆弱性がありました。信頼できるパートナーからの攻撃の影響を最も受けやすいものが、SSO Web ブラウザープロファイルです。この特定のセキュリティ問題は、SAML Response に必須のデータ要素 (安全なメッセージ交換に必要なもの) の一部が含まれていなかったために露わになりました。次に示す AuthnRequest (4.1.4.1) および Response (4.1.4.2) に関する SAML プロファイルの使用上の要件は、この攻撃の対策に役立ちます。AVANTSSAR チームでは、次のデータ要素を必須にする必要があると提案しています。
- AuthnRequest(ID、SP): AuthnRequest には ID と SP を含める必要があります。ID はリクエストを一意に識別する文字列です。SP によりリクエストを開始したサービスプロバイダーを識別します。さらに、レスポンスではリクエスト ID 属性を返す必要があります (InResponseTo="")。InResponseTo は、信頼できる IdP からの応答の信頼性を保証するために役立ちます。これは、Google の SSO を脆弱な状態にしていた、欠落していた属性の 1 つです。
- Response(ID、SP、IdP、{AA} K -1/IdP): Response には、これらの要素がすべて含まれている必要があります。ID はレスポンスを一意に識別する文字列です。SP によりレスポンスの受信者を識別します。IdP により、レスポンスを認可している ID プロバイダーを識別します。{AA} K -1/IdP は、IdP の秘密鍵でデジタル署名したアサーションです。
- AuthAssert(ID、C、IdP、SP): Response には認証アサーションが含まれている必要があります。これには、ID、クライアント (C)、ID プロバイダー (IdP)、およびサービスプロバイダー (SP) 識別子が含まれる必要があります。
SAML 実装のその他の脆弱性については、2012 年に説明されています (「On Breaking SAML: Be Whoever You Want to Be」)。それに応じて、次に示す推奨事項が提案されました (「Secure SAML validation to prevent XML signature wrapping attacks」)。
- セキュリティ関連の目的に使用する前に必ず、XML ドキュメントのスキーマの検証を実行します。
- 検証には、必ずスキーマの信頼できるローカルのコピーを使用します。
- サードパーティの保管場所からの、スキーマの自動ダウンロードは絶対に許可してはいけません。
- 可能な場合は、スキーマを調べて、想定されるワイルドカード型や型指定の緩いステートメントの処理を無効にして、スキーマの強化を実行します。
- デジタル署名を確実に検証します。
- 署名鍵を 1 つのみ想定している場合は、StaticKeySelector を使用します。ID プロバイダーから鍵を直接取得し、ローカルファイルに保存して、ドキュメント内のすべての KeyInfo 要素を無視します。
- 複数の署名鍵を想定している場合は、X509KeySelector (JKS のバリアント) を使用します。これらの鍵を ID プロバイダーから直接取得し、ローカルの JKS に保存して、ドキュメント内の KeyInfo 要素はすべて無視します。
- 複数の署名済みドキュメント (多数の ID プロバイダーからの多数の証明書、複数レベルの検証パス) を想定している場合は、PKIX と信頼できるルート証明書に基づいた、完全な信頼確立モデルを実装します。
- シグネチャラッピング攻撃を回避します。
- 事前の検証なしで、getElementsByTagName を使用して、XML ドキュメント内のセキュリティ関連要素を選択してはいけません。
- 検証に強化したスキーマを使用する場合を除き、常に、絶対 XPath 表現を使用して要素を選択します。
プロトコル処理ルールの検証
アサートのための手順数が膨大なため、これはセキュリティギャップのもう 1 つの共通領域になります。SAML Response の処理は負担の大きな操作ですが、すべての手順を検証する必要があります。
- AuthnRequest 処理のルールを検証します。AuthnRequest の処理ルールの詳細については、SAML コアに関するセクション (3.4.1.4) を参照してください。この手順は、次に示す攻撃への対策に役立ちます。
- Man-in-the-middle (中間者) 6.4.2
- Response 処理のルールを検証します。Response の処理ルールの詳細については、SAML プロファイルに関するセクション (4.1.4.3) を参照してください。この手順は、次に示す攻撃への対策に役立ちます。
- Stolen Assertion (盗難アサーション) 6.4.1
- Man-in-the-middle (中間者) 6.4.2
- Forged Assertion (偽造アサーション) 6.4.3
- Browser State Exposure (ブラウザー状態の公開) 6.4.4
バインディングの実装の検証
- HTTP リダイレクトバインディングについては、SAML バインディングに関するセクション (3.4).を参照してください。エンコードの例を確認する場合は、Google のリファレンス実装にある RequestUtil.java を参照するとよいでしょう。
- HTTP POST バインディングについては、SAML バインディングに関するセクション (3.5) を参照してください。キャッシュについての考慮事項も、非常に重要です。SAML プロトコルメッセージがキャッシュされると、そのメッセージは後に盗難アサーション (6.4.1) やリプレイ攻撃 (6.4.5) として使用される可能性があります。
セキュリティ対抗策の検証
SAML セキュリティのドキュメントに記載されている各セキュリティ問題について再検討し、独自の実装に存在する可能性がある脅威に適切な対抗策を適用していることをアサートします。追加の対策として、次のものが必要になると考えられます。
- IP フィルタリングの使用を優先する (適切な場合)。たとえば、Google が信頼できるパートナーのそれぞれに別のエンドポイントを提供して、各エンドポイントに IP フィルターをセットアップしていた場合、Google の初期のセキュリティ問題は、この対策で防止できたでしょう。この手順は、次に示す攻撃への対策に役立ちます。
- Stolen Assertion (盗難アサーション) 6.4.1
- Man-in-the-middle (中間者) 6.4.2
- 有効期限の短い SAML レスポンス の使用を優先する。この手順は、次に示す攻撃への対策に役立ちます。
- Stolen Assertion (盗難アサーション) 6.4.1
- Browser State Exposure (ブラウザー状態の公開) 6.4.4
- SAML レスポンス に OneTimeUse の使用を優先する。この手順は、次に示す攻撃への対策に役立ちます。
- Browser State Exposure (ブラウザー状態の公開) 6.4.4
- Replay (リプレイ) 6.4.5
アーキテクチャ図が必要ですか？SAML のテクニカルオーバービューには、ほぼ完全な図が記載されています。リダイレクト / POST バインディングを使用した Web ブラウザー SSO プロファイルについては、セクション 4.1.3 を参照してください。実際、数ある SAML ドキュメントの中でも、全体的に見て最重要といえるドキュメントがテクニカルオーバービューです。
ファーストマイルとラストマイルの検討事項
SAML プロトコルが優先的なベクトルになることはほとんどありませんが、SAML プロトコルを確実に堅牢なものにするためのチートシートを用意しておくことは重要です。各種のエンドポイントが標的にされることが多いため、実際問題としては、SAML トークンの生成方法と利用方法の両方が重要になります。
ファーストマイルの検討事項
- アルゴリズムの互換性、暗号化の強度、エクスポートの規制について、X.509 証明書を検証する
- SAML トークンの生成について、強力な認証のオプションを検証する
- IDP を検証する (トークンを作成する IDP)
- ルート CA を使用 / 信頼する (可能な場合)
- 一般的なインターネットタイムソースと同期する
- 本人確認の保証のレベルを定義する
- 個人を特定できる情報 (SSN など) による ID アサーションには、非対称識別子の使用を優先する
- アサーションに署名する (可能な場合)
ラストマイルの検討事項
- ユーザーのセッション状態の検証
- SAML トークン利用時の、authZ コンテキストの設定における詳細度 (グループ、ロール、属性を使用しているか)
- 認可された IDP を検証する
- CRL / OCSP との対比で IDP 証明書の失効を検証する
- NotBefore および NotOnorAfter を検証する
- SAML ログアウトの条件を定義する
- 安全なトランスポートのみを経由してアサーションを交換する
- セッション管理の条件を定義する
- 署名を検証する (可能な場合)
- SAML チケットのアサーションから取得されたユーザー IDを検証する (可能な場合)。
入力検証
SAML がセキュリティプロトコルだからといって、入力検証がなくなるわけではありません。
- すべての SAML プロバイダー / コンシューマーでは、適切な入力検証を行うようにします。
Authors and Primary Editors
Other Cheatsheets
Developer Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets
OpSec Cheat Sheets (Defender)
Draft Cheat Sheets
| 
