V3: セッション管理

管理目標

Web ベースのアプリケーションやステートフル API の中核となるコンポーネントの一つは、それと対話するユーザやデバイスの状態を制御および保守するメカニズムです。セッション管理はステートレスプロトコルをステートフルに変更します。これはさまざまなユーザやデバイスを区別するために重要です。

検証対象のアプリケーションが以下の上位のセッション管理要件を満たすことを確認します。

• セッションは各個人に固有のものであり、推測や共有することはできません。

• セッションは不要になったときや非アクティブ期間内にタイムアウトしたときに無効になります。

前述のように、これらの要件は、一般的な脅威や一般的に悪用される認証脆弱性にフォーカスした、選択された NIST SP 800-63B 管理策の準拠サブセットとなるように適合されています。以前の検証要件は廃止、重複削除、またはほとんどの場合、必須の NIST SP 800-63B 要件の意図と厳密に一致するように調整されています。

V3.1 基本的なセッション管理セキュリティ

#	説明	L1	L2	L3	CWE	NIST §
3.1.1	[削除, 8.3.1 へマージ]
3.1.2	[追加] アプリケーションが信頼できるバックエンドサービスを使用してすべてのセッショントークン検証を実行している。	✓	✓	✓	603
3.1.3	[修正, 3.5.2 から移動, レベル L2 > L1] アプリケーションがセッション管理に暗号署名されたトークンまたは不透明トークンを使用している。静的な API シークレットと API キーは避けるべきである。	✓	✓	✓	798	7.1

V3.2 セッションバインディング

#	説明	L1	L2	L3	CWE	NIST §
3.2.1	[修正] アプリケーションがユーザ認証 (再認証を含む) 時に新しいセッショントークンを生成し、現在のセッショントークンを終了する。	✓	✓	✓	384	7.1
3.2.2	[修正] opaque セッショントークンが少なくとも 128 ビットのエントロピーを有する。	✓	✓	✓	331	7.1
3.2.3	[削除, 8.2.2 へマージ]
3.2.4	[修正] opaque セッショントークンがセキュアなランダム関数を使用して生成されている。		✓	✓	330	7.1
3.2.5	[追加] アプリケーションのセッションを作成するにはユーザの同意が必要であり、ユーザとのやり取りなしで SSO 経由でユーザの新しいアプリケーションセッションが作成される CSRF スタイルの攻撃からアプリケーションを保護している。		✓	✓

TLS や他のセキュアなトランスポートチャネルはセッション管理に必須です。これは通信セキュリティの章でカバーされています。

V3.3 セッションタイムアウト

セッションタイムアウトは NIST SP 800-63 と整合しています。これはセキュリティ標準で旧来許可されているよりもはるかに長いセッションタイムアウトを許可します。組織は以下の表をレビューすることをお勧めします。アプリケーションのリスクプロファイルに基づいてより長いタイムアウトが望まれる場合には、NIST 値がセッションアイドルタイムアウトの最大限度として機能するはずです。

このコンテキストでの L1 は IAL1/AAL1, L2 は IAL2/AAL3, L3 は IAL3/AAL3 です。IAL2/AAL2 および IAL3/AAL3 の両方では、アイドルタイムアウトはより短くなり、ログアウトやセッションを再開するための再認証にはアイドルタイムの下限とします。

#	説明	L1	L2	L3	CWE	NIST §
3.3.1	[3.8.1 へ移動]
3.3.2	[修正, 3.3.5 へ分割] L1 アプリケーションでは少なくとも 30 日ごと、L2 および L3 アプリケーションでは 12 時間ごとに再認証が必要となるような絶対最大セッション存続期間がある。	✓	✓	✓	613	7.2
3.3.3	[3.8.2 へ移動]
3.3.4	[3.8.3 へ移動]
3.3.5	[追加, 3.3.2 から分割] L2 アプリケーションでは 30 分の非アクティブ状態経過後、L3 アプリケーションでは 15 分の非アクティブ状態経過後に再認証が必要となる。		✓	✓	613	7.2

V3.4 Cookie ベースのセッション管理

#	説明	L1	L2	L3	CWE	NIST §
3.4.1	Cookie ベースのセッショントークンには 'Secure' 属性が設定されている。	✓	✓	✓	614	7.1.1
3.4.2	[修正] Cookie ベースのセッショントークンはクライアントサイドのスクリプトで読み取れない。セッショントークン Cookie には 'HttpOnly' 属性が設定されている必要があり、セッショントークン値は Set-Cookie ヘッダを介してのみクライアントに転送される必要がある。	✓	✓	✓	1004	7.1.1
3.4.3	Cookie ベースのセッショントークンには、クロスサイトリクエストフォージェリ攻撃への露出を制限するために、'SameSite' 属性を利用している。	✓	✓	✓	1275	7.1.1
3.4.4	Cookie ベースのセッショントークンには "__Host-" プレフィックスを使用しており、Cookie は最初に Cookie を設定したホストにのみ送信されている。	✓	✓	✓	16	7.1.1
3.4.5	[削除, 50.1.1 により廃止]

V3.5 トークンベースのセッション管理

トークンベースのセッション管理には JWT, OAuth, SAML, API キーが含まれます。これらのうち、API キーは脆弱であることが分かっているため、新しいコードでは使用すべきではありません。 JWT と SAML トークンはステートレスセッショントークンの一例です。以下に記載されているすべてのチェックは上述のように信頼できるバックエンドサービスによって実施されるべきです。

#	説明	L1	L2	L3	CWE	NIST §
3.5.1	[文法] アプリケーションはリンクされたアプリケーションとの信頼関係を形成する OAuth トークンを取り消すことをユーザに許可する。		✓	✓	290	7.1.2
3.5.2	[3.1.3 へ移動]
3.5.3	[修正, レベル L2 > L1] ステートレスセッショントークンは改竄から保護するためにデジタル署名を使用し、さらに処理する前にこれをチェックしている。	✓	✓	✓	345
3.5.4	[追加] ステートレストークンはさらなる処理の前に有効期限がチェックされている。	✓	✓	✓	613
3.5.5	[追加] ステートレストークンでは許可リストに記載された署名アルゴリズムのみが許可されている。	✓	✓	✓	757
3.5.6	[追加] ステートレストークンのその他のセキュリティセンシティブな属性が検証されている。例えば、JWT ではこれには issuer, subject, audience などがある。	✓	✓	✓	287
3.5.7	[追加] 管理者がユーザーの権限や役割を変更する際に、アクセス制御の決定に依拠しているアクティブなステートレストークンが取り消される。	✓	✓	✓	613

V3.6 Federated 再認証

このセクションは Relying Party (RP) またはクレデンシャルサービスプロバイダ (Credential Service Provider, CSP) のコードを書いている人に関するものです。これらの機能を実装するコードに依存する場合には、これらの問題が正しく処理されていることを確認します。

#	説明	L1	L2	L3	CWE	NIST §
3.6.1	Relying Party がクレデンシャルサービスプロバイダ (Credential Service Provider, CSP) に最大認証時間を指定していること、および CSP がその期間内にセッションを使用していない場合には CSP がユーザを再認証する。			✓	613	7.2.1
3.6.2	RP がユーザを再認証する必要があるかどうかを RP が判断できるようにするために、クレデンシャルサービスプロバイダ (Credential Service Provider, CSP) が Relying Party に最後の認証イベントを通知する。			✓	613	7.2.1

V3.7 セッション管理の悪用に対する防御

少数のセッション管理攻撃がありますが、そのいくつかはセッションのユーザエクスペリエンス (UX) に関連しています。以前は、ISO 27002 要件に基づいて、ASVS は複数の同時セッションをブロックすることを要求していました。最近のユーザは多くのデバイスを使用しているだけでなく、アプリはブラウザセッションを使用しない API であるため、同時セッションのブロックはもはや適切ではありません。これらの実装のほとんどでは、最終認証者が勝利します。それはおおよそ攻撃者です。このセクションでは、コードを使用したセッション管理攻撃の阻止、遅延、検出に関する主要なガイダンスを提供します。

ハーフオープン攻撃の説明

2018 年初頭、攻撃者が「ハーフオープン攻撃」と呼ぶものを使用して、いくつかの金融機関が侵害されました。この用語は業界に受け入れられています。攻撃者はさまざまな独自のコードベースを使用して複数の機関を攻撃しました。実際、同じ機関内でもコードベースが異なるようです。ハーフオープン攻撃は、多くの認証、セッション管理、およびアクセス制御システムで一般的に存在する設計パターンの欠陥を悪用します。

攻撃者は、クレデンシャルをロック、リセット、リカバリーしようと試みることにより、ハーフオープン攻撃を開始します。一般的なセッション管理デザインパターンは、未認証、半認証 (パスワードリセット、ユーザ名忘れ) 、完全認証コードの間でユーザプロファイルセッションオブジェクトやモデルを再利用します。このデザインパターンは、パスワードハッシュやロールなど、被害者のプロファイルを含む有効なセッションオブジェクトやまたはトークンを入力します。コントローラまたはルータのアクセス制御チェックでユーザが完全にログインしていることを正しく検証していない場合、攻撃者はそのユーザとして行動できるかもしれません。攻撃には、ユーザのパスワードを既知の値に変更する、有効なパスワードリセットを実行するために電子メールアドレスを更新する、多要素認証を無効にする、新しい MFA デバイスを登録する、API キーを公開または変更する、などがあります。

#	説明	L1	L2	L3	CWE	NIST §
3.7.1	[修正] 機密性の高いトランザクション、アカウントプロファイルや認証設定の変更、または機密データの大規模なエクスポートを許可する前に、アプリケーションが再認証や二次検証を必要としている。	✓	✓	✓	306

V3.8 セッションの終了

セッションの終了はアプリケーション自体によって処理されるか、SSO プロバイダ がアプリケーションの代わりにセッション管理を処理している場合は SSO プロバイダによって処理されます。いくつかの要件はプロバイダによってコントロールされる可能性があるため、このセクションの要件を検討する際に、SSO プロバイダが適用範囲に含まれるかどうかを判断する必要があるかもしれません。

セッションの終了は再認証を必要とし、アプリケーション、Federated ログイン (存在する場合) 、Relying Party すべてに有効である必要があります。

ステートフルセッションメカニズムの場合、これはバックエンドでセッションを無効にするだけで済みます。署名付きトークンでのステートレスセッションメカニズムを使用している場合、これらのトークンを取り消す方法が必要になります。

#	Description	L1	L2	L3	CWE	NIST §
3.8.1	[修正, 3.3.1 から移動] 戻るボタンやダウンストリーム Relying Party が認証済みセッションを再開できないように、ログアウトおよび有効期限切れがユーザーのセッションを終了する。	✓	✓	✓	613	7.1
3.8.2	[修正, レベル L2 > L1, 3.3.3 から移動] 認証要素が正常に変更または削除 (リセットやリカバリーによるパスワード変更や、存在する場合、MFA 設定の更新を含む) された後、アプリケーションが他のすべてのアクティブセッションを終了するためのオプションを提供している。	✓	✓	✓	613
3.8.3	[修正, 3.3.4 から移動] ユーザが現在アクティブなセッションのいずれかまたはすべてを閲覧および (ログインクレデンシャルを再入力して) 終了できる。		✓	✓	613	7.1
3.8.4	[追加] 認証を必要とするすべてのページでログアウト機能に簡単かつ目に見える形でアクセスできる。		✓	✓
3.8.5	[追加] ユーザアカウントが無効または削除された場合 (従業員の退職など) 、アプリケーションはすべてのアクティブなセッションを終了する。	✓	✓	✓	613
3.8.6	[追加] アプリケーション管理者は個々のユーザーまたはすべてのユーザーのアクティブなセッションを終了できる。	✓	✓	✓	613	7.1

参考情報

詳しくは以下の情報を参照してください。

• OWASP Testing Guide 4.0: Session Management Testing

• OWASP Session Management Cheat Sheet

• Set-Cookie __Host- prefix details