多くの ASVS 要件は、認証やアクセス制御などの特定のセキュリティ領域に関連しているか、ログ記録やファイル処理などの特定のタイプのアプリケーション機能に関連しています。
しかし、この章ではアプリケーションのビルド方法と安全なコードを正しく記述する方法について、より一般的なガイダンスを提供します。クリーンなアーキテクチャとコード品質の観点からだけでなく、アプリケーションを安全にするために従う必要がある特定のアーキテクチャとコーディングプラクティスについても説明します。
この章にはアプリケーションへの悪意のあるコードの侵入を防ぐための要件も含みます。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.10.1 | [削除, スコープ外] | ||||
| 1.10.2 | [修正, 14.2.5 から移動, 14.2.4 からマージ, 12.3.6 をカバー] 使用しているすべてのサードパーティライブラリについて、ソフトウェア部品表 (SBOM) などのインベントリカテゴリを保守している。コンポーネントは事前定義済みで信頼でき、継続的に保守されているリポジトリから取得している。 | ✓ | ✓ | ||
| 1.10.3 | [追加, 14.2.6 から分割] アプリケーションドキュメントでは「危険な」サードパーティライブラリを強調している。これには、セキュリティの観点から危険な操作を実行するライブラリ、メンテナンスが不十分なライブラリ、サポートされていないライブラリ、サポートが終了したライブラリ、歴史的にいくつかの重大な脆弱性を抱えているライブラリなどが含まれる。 | ✓ | 1061 | ||
| 1.10.4 | [追加, 1.14.5 から分割] アプリケーションドキュメントではアプリケーションで「危険な」操作が実行されている部分を強調している。このコンテキストでの「危険な」とは、信頼できないデータの逆シリアル化、生のファイルの解析、直接的なメモリ操作など、危険な悪用が行われる可能性が高いものを意味する。 | ✓ | |||
| 1.10.5 | [追加D, 14.2.1 から分割, 1.14.3 をカバー] アプリケーションドキュメントでは、脆弱性があるサードパーティコンポーネントのバージョンやライブラリ全般の更新について、リスクに基づく修復時間枠を定義して、これらのコンポーネントからのリスクを最小限に抑えている。 | ✓ | ✓ | ✓ |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.1.1 | [削除, スコープ外] |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.2.1 | [削除, 非現実的] | ||||
| 10.2.2 | [削除, 非現実的] | ||||
| 10.2.3 | [削除, 非現実的] | ||||
| 10.2.4 | [削除, 非現実的] | ||||
| 10.2.5 | [削除, 非現実的] | ||||
| 10.2.6 | [削除, 非現実的] |
アプリケーションがデプロイされた後も、悪性コードが挿入される可能性があります。 アプリケーションは、信頼されていないソースからの未署名のコードの実行やサブドメインテイクオーバ（subdomain takeover）などの一般的な攻撃から自身を保護する必要があります。
このセクションに準拠するには運用上、持続的に進める必要があります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.3.1 | [修正, レベル L1 > L3] アプリケーションに自動更新機能がある場合、更新はデジタル署名され、更新をインストールまたは実行する前にデジタル署名が検証されている必要がある。 | ✓ | 16 | ||
| 10.3.2 | [削除, 10.6.2 へ移動] | ||||
| 10.3.3 | [削除, スコープ外] |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.4.1 | [追加] アプリケーションは変数が正しい型であることを明示的に保証し、厳密な等価演算と比較演算を実行して、アプリケーションコードが変数の型について仮定することによって引き起こされる型ジャグリングや型コンフュージョンの脆弱性を回避している。 | ✓ | ✓ | ✓ | 843 |
| 10.4.2 | [追加] アプリケーションは、明示的な変数宣言の採用、厳密な型チェックの実行、document オブジェクトへのグローバル変数の保存の回避、名前空間分離の実装によって、クライアントサイド JavaScript を使用する際の DOM clobbering を回避している。 | ✓ | ✓ | 79 | |
| 10.4.3 | [追加] JavaScript コードはオブジェクトリテラルの代わりに Set() や Map() を使用するなど、プロトタイプ汚染を防ぐ方法で記述している。 | ✓ | ✓ | ||
| 10.4.4 | [修正, 5.1.2 から移動] アプリケーションには、コントローラやアクションごとに許可されるフィールドを制限することで、大量割り当て攻撃から保護する対策がある。たとえば、そのアクションの一部となることを意図していないフィールド値を挿入または更新することはできない。 | ✓ | ✓ | ✓ | 915 |
| 10.4.5 | [追加] アプリケーションはユーザがアクセスするためのパーミッションを持つデータのみを返している。たとえば、API レスポンスは、データオブジェクト自体にアクセスするためのパーミッションを持っていたとしても、ユーザがアクセスするためのパーミッションを持たない値を含む属性での完全なオブジェクトを返さない。 | ✓ | ✓ | ✓ | |
| 10.4.6 | [追加] アプリケーションはレート制限やログ記録などの機密性の高い機能を提供するために、ユーザの実際の IP アドレスを識別して利用できる。 | ✓ | ✓ | 348 | |
| 10.4.7 | [修正, 5.1.1 から移動, レベル L1 > L2] アプリケーションが HTTP 変数汚染攻撃に対する防御策を備えている。特にアプリケーションフレームワークが、リクエストパラメータのソース (クエリ文字列、ボディパラメータ、Cookie、ヘッダフィールド) を区別しない場合はこの防御が必要。 | ✓ | ✓ | 235 | |
| 10.4.8 | [追加] アプリケーションバックエンドが外部 URL を呼び出す場合、意図した機能でない限りリダイレクトに従わないように設定されている。 | ✓ | ✓ |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.5.1 | [追加, 1.14.5, 14.2.6 から分割] アプリケーションは、アプリケーションで「危険な」操作を実行したり「危険な」サードパーティライブラリを使用していると文書化されている部分に対して追加の保護を実装している。これには、サンドボックス化、カプセル化、コンテナ化、ネットワークレベルの分離などの技法が含まれ、アプリケーションの一部分を侵害した攻撃者がアプリケーションの他の部分に侵入するのを遅らせたり阻止する。 | ✓ |
依存関係管理はあらゆる種類のアプリケーションを安全に運用するために不可欠です。古い依存関係やセキュアでない依存関係で最新に保てないことが、これまでで最大かつ最高となる攻撃の根本原因です。パッチで最新に保つことは不可欠ですが、公開された脆弱性に対する更新のみに頼ると、ベンダーがセキュリティ問題を公表せずに修正する可能性があるため、リスクを伴います。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.6.1 | [追加, 14.2.1 から分割, 1.14.3 をカバー] アプリケーションは、文書化された更新および修復の時間枠に違反していないコンポーネントのみを含む。 | ✓ | ✓ | ✓ | |
| 10.6.2 | [修正, 10.3.2 から移動] サードパーティコンポーネントとそのすべての推移的依存関係は、内部所有であるか外部ソースであるかに関わらず、想定されたリポジトリから組み込まれており、依存関係攪乱攻撃のリスクはない。 | ✓ | ✓ | ✓ | 427 |
適切な同期を行わないと、共有リソースのへの同時アクセスはデータの破損、システムクラッシュ、信頼できないアプリケーション動作を引き起こす可能性があります。さらに、レースコンディションが連鎖して、権限昇格やリモートコード実行が行われることもよくあります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.7.1 | [修正, 1.11.3 から移動] マルチスレッドのコンテキストではスレッドセーフな型のみが使用されるか、スレッドセーフでない型が適切に同期して競合状態を防いでいる。 | ✓ | 362 | ||
| 10.7.2 | [修正, 1.11.2 から移動, レベル L2 > L3] 共有リソースへの同時アクセスは同期プリミティブ (ロック、ミューテックス、セマフォなど) を使用して制御され、競合状態を防ぎ、これらのリソースに対するアトミック操作を保証している。 | ✓ | 366 | ||
| 10.7.3 | [修正, 11.1.6 から移動] 共有リソースへのすべてのアクセスは一貫してチェックされて、単一のアトミック操作でアクセスされ、Time-of-Check to Time-of-Use (TOC/TOU) 競合状態を防ぎ、チェックと使用の間のリソース状態の一貫性を確保している。 | ✓ | ✓ | 367 | |
| 10.7.4 | [追加] リソース取得では一貫したロック戦略を使用して循環依存関係を回避し、デッドロックとライブロックの両方のシナリオを防いで前進を確保している。 | ✓ | 833 | ||
| 10.7.5 | [追加] リソース割り当てのポリシーは、スレッドプールを活用するなどしてリソースへの公平なアクセスを確保し、優先度の低いスレッドが妥当な時間枠内で処理を進められるようにすることで、スレッドの枯渇を防いでいる。 | ✓ | 410 | ||
| 10.7.6 | [追加] ロックプリミティブは、所有するクラスまたはモジュールにのみアクセス可能で、パブリックに変更可能ではなく、ロックが外部のクラスやコードによって不注意にまたは悪意を持って変更できないようにしている。 | ✓ | 412 |
詳しくは以下の情報を参照してください。