OWASP ASVS 4.0
管理目標 †
Webベースのアプリケーションやステートフル API の中核となるコンポーネントのひとつは、それと対話するユーザやデバイスの状態を制御および保守するメカニズムです。セッション管理はステートレスプロトコルをステートフルに変更します。これはさまざまなユーザやデバイスを区別するために重要です。
検証されるアプリケーションが以下の上位レベルのセッション管理要件を満たしていることを確認します。
- セッションは、各個人に固有のものであり、推測や共有することはできません
- セッションは、不要になったときや非アクティブ期間内にタイムアウトしたときに無効になります
前述のように、これらの要件は、一般的な脅威や一般的に悪用される認証の脆弱性にフォーカスした、選択された NIST 800-63b 管理策の準拠サブセットとなるように適合されています。以前の検証要件は廃止、重複削除、またはほとんどの場合、必須の NIST 800-63b 要件の意図と厳密に一致するように調整されています。
セキュリティ検証要件 †
V3.1 基本的なセッション管理要件 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.1.1 | アプリケーションが URL パラメータやエラーメッセージ内にセッショントークンを漏洩しない。 | ✓ | ✓ | ✓ | 598 | 機密性の高いクエリ文字列を持つ GET | リクエストメソッドの使用 ウェブアプリケーションは、HTTP GET メソッドを使用してリクエストを処理し、そのリクエストのクエリ文字列に機密性の高い情報を含みます。 | |
V3.2 セッションバインディング要件 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.2.1 | アプリケーションがユーザ認証時に新しいセッショントークンを生成する。 (C6) | ✓ | ✓ | ✓ | 384 | セッションの固定化 | 既存のセッション識別子を無効にすることなく、ユーザーを認証するか、あるいは新しいユーザーセッ ションを確立すると、攻撃者は認証されたセッションを盗む機会を得ることができます。 | 7.1 |
| 3.2.2 | セッショントークンに少なくとも64ビットのエントロピーがある。 (C6) | ✓ | ✓ | ✓ | 331 | 不十分なエントロピー | ソフトウェアは、不十分なエントロピーを生成するアルゴリズムまたはスキームを使用しており、他のものよりも発生しやすいパターンまたは値のクラスタを残しています。 | 7.1 |
| 3.2.3 | 適切に保護されたCookie (セクション 3.4 を参照) や HTML 5 セッションストレージなどのセキュアな方法を使用して、アプリケーションがブラウザにセッショントークンのみを保存する。 | ✓ | ✓ | ✓ | 539 | 機密情報を含む永続的なクッキーの使用 | ウェブアプリケーションは永続的なクッキーを使用しますが、クッキーには機密情報が含まれています。 | 7.1 |
| 3.2.4 | セッショントークンが承認済みの暗号化アルゴリズムを使用して生成されている。 (C6) | | ✓ | ✓ | 331 | 不十分なエントロピー | ソフトウェアは、不十分なエントロピーを生成するアルゴリズムまたはスキームを使用しており、他のものよりも発生しやすいパターンまたは値のクラスタを残しています。 | 7.1 |
V3.3 セッションログアウトおよびタイムアウト要件 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.3.1 | 「戻る」ボタンや下流の依拠当事者(Relying Parties)が、依拠当事者(Relying Parties)間を含め認証済みセッションを再開しないように、ログアウトおよび有効期限によってセッショントークンが無効になる。 (C6) | ✓ | ✓ | ✓ | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | 7.1 |
| 3.3.2 | オーセンティケータがユーザにログインしたままでいることを許可する場合、アクティブに使用されているときと、アイドル期間後の両方で、定期的に再認証が行われる。 (C6) | 30日 | 12時間 or 30分のアイドル状態、2FAはオプショナル | 12時間 or 15分のアイドル状態、 2FAを利用 | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | 7.2 |
| 3.3.3 | パスワードが正常に変更された後、アプリケーションが他のすべてのアクティブセッションを終了している。および、これがアプリケーション、フェデレーションログイン（存在する場合）、依拠当事者(Relying Parties)すべてに有効となっている。 | | ✓ | ✓ | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | |
| 3.3.4 | ユーザがすべての現在のアクティブなセッションまたはデバイスを表示、ログアウトできる。 | | ✓ | ✓ | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | 7.1 |
V3.4 クッキーベースのセッション管理 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.4.1 | クッキーベースのセッショントークンに Secure 属性が設定されている。 (C6) | ✓ | ✓ | ✓ | 614 | 「Secure」属性のないHTTPSセッションのセンシティブクッキー | HTTPSセッションのセンシティブクッキーのSecure属性が設定されていないため、ユーザエージェントがHTTPセッション上で平文のクッキーを送信してしまう可能性があります。 | 7.1.1 |
| 3.4.2 | クッキーベースのセッショントークンに HttpOnly 属性が設定されている。 (C6) | ✓ | ✓ | ✓ | 1004 | HttpOnly' フラグなしのセンシティブなクッキー | ソフトウェアは機密情報を保存するためにクッキーを使用しますが、そのクッキーには HttpOnly フラグが付けられていません。 | 7.1.1 |
| 3.4.3 | クロスサイトリクエストフォージェリ攻撃を抑制するために、クッキーベースのセッショントークンが SameSite 属性を利用している。 (C6) | ✓ | ✓ | ✓ | 16 | カテゴリ：構成 | このカテゴリの弱点は、通常、ソフトウェアの構成時に発生します。 | 7.1.1 |
| 3.4.4 | セッションクッキーの機密性を確保するために、クッキーベースのセッショントークンが"__Host-"プレフィックス（参考文献を参照）を使用している。 | ✓ | ✓ | ✓ | 16 | カテゴリ：構成 | このカテゴリの弱点は、通常、ソフトウェアの構成時に発生します。 | 7.1.1 |
| 3.4.5 | セッションクッキーを上書きまたは開示する可能性があるセッションクッキーを設定または使用する他のアプリケーションを持つドメイン名配下でアプリケーションが公開されている場合は、最も正確なパスを使用してクッキーベースのセッショントークンに path 属性を設定している。 (C6) | ✓ | ✓ | ✓ | 16 | カテゴリ：構成 | このカテゴリの弱点は、通常、ソフトウェアの構成時に発生します。 | 7.1.1 |
V3.5 トークンベースのセッション管理 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.5.1 | アプリケーションが、サブスクライバ(Subscriber)として、OAuth および Refresh Token を自ら処理せず、ユーザがリンクされたアプリケーションとの信頼関係を終了できるようにしている。 | | ✓ | ✓ | 290 | なりすましによる認証のバイパス | この攻撃に特化した弱点は、なりすまし攻撃の対象となる認証スキームが不適切に実装されていることによって引き起こされます。 | 7.1.2 |
| 3.5.2 | レガシーな実装を除いて、アプリケーションが静的な API シークレットや API キーではなくセッショントークンを使用している。 | | ✓ | ✓ | 798 | 過剰なデータのロギング | ソフトウェアはあまりにも多くの情報をログに記録するため、ログファイルの処理が困難になり、攻撃後の復旧作業やフォレンジック分析の妨げになる可能性があります。 | |
| 3.5.3 | ステートレスセッショントークンがデジタル署名、暗号化、およびその他の対策を使用して、改ざん、エンベローピング、リプレイ、ヌル暗号、鍵置き換え攻撃から保護されている。 | | ✓ | ✓ | 345 | データの真正性の検証が不十分 | ソフトウェアがデータの起源や真正性を十分に検証しておらず、無効なデータを受け入れる原因となっています。 | |
V3.6 フェデレーションまたはアサーションからの再認証 †
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.6.1 | 依拠当事者(Relying Parties)がCSPに最大認証時間を指定していること、およびCSPがその期間内にセッションを使用していない場合は、CSPがサブスクライバ(Subscriber)を再認証する。 | | | ✓ | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | 7.2.1 |
| 3.6.2 | CSPがユーザを再認証する必要があるかどうかを依拠当事者(Relying Parties)が決定できるように、CSPが依拠当事者(Relying Parties)に最後の認証イベントを通知する。 | | | ✓ | 613 | 不十分なセッションの有効期限 | WASCによると、「不十分なセッションの有効期限とは、Webサイトが攻撃者に古いセッション認証情報やセッションIDを再利用して認証を行うことを許すことである」とされている。 | 7.2.1 |
V3.7 セッション管理の悪用に対する防御 †
数は少ないがセッション管理に対する攻撃があり、そのいくつかはセッションのユーザエクスペリエンス（UX）に関連しています。以前は、ISO 27002 要件に基づいて、ASVS は複数の同時セッションをブロックすることを要求していました。最近のユーザは多くのデバイスを使用しているだけでなく、アプリはブラウザセッションを使用しない API であるため、同時セッションのブロックはもはや適切ではありません。これらの実装のほとんどでは、最終認証者が勝利します。それはおおよそ攻撃者です。このセクションでは、コードを使用したセッション管理に対する攻撃の阻止、遅延、検出に関する主要なガイダンスを提供します。
ハーフオープン攻撃の説明 †
2018年初頭、攻撃者が「ハーフオープン攻撃」と呼ぶものを使用して、いくつかの金融機関が侵害されました。この用語は業界に受け入れられています。攻撃者はさまざまな独自のコードベースを使用して複数の機関を攻撃しました。実際、同じ機関内でもコードベースが異なるようです。ハーフオープン攻撃は、多くの既存の認証、セッション管理、およびアクセス制御システムで一般的にみられる設計パターンの欠陥を悪用しています。
攻撃者は、クレデンシャルをロック、リセット、リカバリしようと試みることにより、ハーフオープン攻撃を開始します。一般的なセッション管理デザインパターンは、未認証、半認証 (パスワードリセット、ユーザ名忘れ) 、完全認証コードの間でユーザプロファイルセッションオブジェクトやモデルを再利用します。このデザインパターンは、パスワードハッシュやロールなど、被害者のプロファイルを含む有効なセッションオブジェクトやまたはトークンを入力します。コントローラまたはルータのアクセス制御チェックでユーザが完全にログインしていることを正しく検証していない場合、攻撃者はそのユーザとして行動できるかもしれません。攻撃には、ユーザのパスワードを既知の値に変更する、有効なパスワードリセットを実行するために電子メールアドレスを更新する、多要素認証を無効にする、新しい MFA デバイスを登録する、API キーを公開または変更する、などがあります。
| 項番 | 説明 | L1 | L2 | L3 | CWE No | タイトル | 概要 | NIST |
| 3.7.1 | 機密性の高いトランザクションやアカウントの変更を許可する前に、アプリケーションが完全で有効なログインセッションを確保していること、または再認証や二次検証を必要としている。 | ✓ | ✓ | ✓ | 778 | 不十分なロギング | セキュリティ上重要なイベントが発生した場合、ソフトウェアはイベントを記録しないか、ログを記録する際にイベントに関する重要な詳細を省略します。 | |
参考情報 †
詳しくは以下の情報を参照してください。
