V15: セキュアコーディングアーキテクチャと実装
管理目標
多くの ASVS 要件は、認証や認可などの特定のセキュリティ領域に関連しているか、ログ記録やファイル処理などの特定のタイプのアプリケーション機能に関連しています。
しかし、この章ではアプリケーションのビルド方法と安全なコードを正しく記述する方法について、より一般的なガイダンスを提供します。クリーンなアーキテクチャとコード品質の観点からだけでなく、アプリケーションを安全にするために従う必要がある特定のアーキテクチャとコーディングプラクティスについても説明します。
この章にはアプリケーションへの悪意のあるコードの侵入を防ぐための要件も含みます。
V15.1 セキュアコーディングドキュメント
安全で防御可能なアーキテクチャに必要な要件の多くは、アプリケーションで使用されるコンポーネントに関する明確なドキュメントを持つことを必要とします。このセクションでは、これらのコンポーネントのうち、保守が不十分であったり、サポートされていなかったり、サポートを終了していたり、重大な脆弱性の履歴があるためにリスクのあるコンポーネントや、信頼できないデータの逆シリアル化、生のファイルの解析、直接的なメモリ操作などの危険な操作を実行するコンポーネントなど、このドキュメントの要件を示します。また、サードパーティコンポーネントの脆弱性に対処するための適切なタイムスケールを定義することも義務付けています。
1.10.5
[追加, 14.2.1 から分割, 1.14.3 をカバー] アプリケーションドキュメントでは、脆弱性があるサードパーティコンポーネントのバージョンやライブラリ全般の更新について、リスクに基づく修復時間枠を定義して、これらのコンポーネントからのリスクを最小限に抑えている。
1
v5.0.be-1.10.5
1.10.2
[修正, 14.2.5 から移動, 14.2.4 からマージ, 12.3.6 をカバー] 使用しているすべてのサードパーティライブラリについて、ソフトウェア部品表 (SBOM) などのインベントリカテゴリを保守している。コンポーネントは事前定義済みで信頼でき、継続的に保守されているリポジトリから取得している。
2
v5.0.be-1.10.2
1.10.6
[追加] アプリケーションドキュメントでは、時間のかかる機能やリソースを必要とする機能を特定している。これには、この機能の過剰使用による可用性の損失を防ぐ方法や、レスポンスの構築にコンシューマのタイムアウトよりも長い時間がかかる状況を避ける方法を含む必要がある。可能性のある防御策としては、非同期処理、キューの使用、ユーザごとおよびアプリケーションごとの並列処理の制限などがある。
2
v5.0.be-1.10.6
1.10.3
[追加, 14.2.6 から分割] アプリケーションドキュメントでは「危険な」サードパーティライブラリを強調している。これには、セキュリティの観点から危険な操作を実行するライブラリ、メンテナンスが不十分なライブラリ、サポートされていないライブラリ、サポートが終了したライブラリ、歴史的にいくつかの重大な脆弱性を抱えているライブラリを含む必要がある。
3
v5.0.be-1.10.3
1.10.4
[追加, 1.14.5 から分割] アプリケーションドキュメントではアプリケーションで「危険な」操作が実行されている部分を強調している。このコンテキストでの「危険な」とは、信頼できないデータの逆シリアル化、生のファイルの解析、直接的なメモリ操作など、危険な悪用が行われる可能性が高いものを意味する。
3
v5.0.be-1.10.4
V15.2 セキュリティアーキテクチャと依存関係
このセクションでは、依存関係管理を通じてリスクのある、古い、または安全でない依存関係とコンポーネントを処理するための要件を含みます。また、サンドボックス化、カプセル化、コンテナ化、ネットワーク分離などのアーキテクチャレベルの技法を使用して、リスクのある操作やライブラリの影響を軽減し、リソースを必要とする機能の過剰使用による可用性の損失を防ぐことも含みます。
10.6.1
[追加, 14.2.1 から分割, 1.14.3 をカバー] アプリケーションは、文書化された更新および修復の時間枠に違反していないコンポーネントのみを含む。
1
v5.0.be-10.6.1
10.6.4
[追加] アプリケーションは、これに関する文書化されたセキュリティ上の決定と戦略に基づいて、時間のかかる機能やリソースを必要とする機能による可用性の損失に対する防御策を実装している。
2
v5.0.be-10.6.4
10.6.2
[修正, 10.3.2 から移動] サードパーティコンポーネントとそのすべての推移的依存関係は、内部所有であるか外部ソースであるかに関わらず、想定されたリポジトリから組み込まれており、依存関係攪乱攻撃のリスクはない。
3
v5.0.be-10.6.2
10.6.3
[追加, 1.14.5, 14.2.6 から分割] アプリケーションは、アプリケーションで「危険な」操作を実行したり「危険な」サードパーティライブラリを使用していると文書化されている部分に対して追加の保護を実装している。これには、サンドボックス化、カプセル化、コンテナ化、ネットワークレベルの分離などの技法が含まれ、アプリケーションの一部分を侵害した攻撃者がアプリケーションの他の部分に侵入するのを遅らせたり阻止する。
3
v5.0.be-10.6.3
V15.3 防御的コーディング
このセクションでは、型ジャグリング、プロトタイプ汚染、大量割り当てなど、特定の言語における安全でないコーディングパターンの使用に起因する脆弱性の種類について説明します。一部はすべての言語に関係しないかもしれない一方で、他のものは言語固有の修正があったり、特定の言語やフレームワークが HTTP パラメータなどの機能を処理する方法に関係するかもしれません。また、アプリケーションの更新を暗号的に検証しないことのリスクも考慮します。
10.4.5
[追加] アプリケーションはユーザがアクセスするためのパーミッションを持つデータのみを返している。たとえば、API レスポンスは、データオブジェクト自体にアクセスするためのパーミッションを持っていたとしても、ユーザがアクセスするためのパーミッションを持たない値を含む属性での完全なオブジェクトを返さない。
1
v5.0.be-10.4.5
10.4.8
[追加] アプリケーションバックエンドが外部 URL を呼び出す場合、意図した機能でない限りリダイレクトに従わないように設定されている。
2
v5.0.be-10.4.8
10.4.4
[修正, 5.1.2 から移動] アプリケーションには、コントローラやアクションごとに許可されるフィールドを制限することで、大量割り当て攻撃から保護する対策がある。たとえば、そのアクションの一部となることを意図していないフィールド値を挿入または更新することはできない。
2
v5.0.be-10.4.4
10.4.6
[追加] アプリケーションはレート制限やログ記録などの機密性の高い機能を提供するために、ユーザの実際の IP アドレスを識別して利用できる。
2
v5.0.be-10.4.6
10.4.1
[追加] アプリケーションは変数が正しい型であることを明示的に保証し、厳密な等価演算と比較演算を実行している。これは、アプリケーションコードが変数の型について仮定することによって引き起こされる型ジャグリングや型コンフュージョンの脆弱性を回避するためである。
2
v5.0.be-10.4.1
10.4.3
[追加] JavaScript コードはオブジェクトリテラルの代わりに Set() や Map() を使用するなど、プロトタイプ汚染を防ぐ方法で記述している。
2
v5.0.be-10.4.3
10.4.7
[修正, 5.1.1 から移動, レベル L1 > L2] 特にアプリケーションフレームワークがリクエストパラメータ (クエリ文字列、ボディパラメータ、クッキー、ヘッダフィールド) のソースについて区別していない場合、アプリケーションが HTTP パラメータ汚染攻撃を防御している。
2
v5.0.be-10.4.7
10.4.2
[追加] アプリケーションは、明示的な変数宣言の採用、厳密な型チェックの実行、document オブジェクトへのグローバル変数の保存の回避、名前空間分離の実装によって、クライアントサイド JavaScript を使用する際の DOM clobbering を回避している。
3
v5.0.be-10.4.2
10.4.9
[追加] アプリケーション (バックエンドまたはフロントエンド) がリクエストを構築して送信する場合、バリデーション、サニタイゼーション、またはその他のメカニズムを使用して、受信コンポーネントで受け入れられるには長すぎる URI (API 呼び出しのためなど) や HTTP リクエストヘッダフィールド (認可やクッキーのためなど) の作成を回避している。長すぎるリクエスト (長いクッキーヘッダフィールドなど) を送信すると、サーバが常にエラーステータスで応答するなど、サービス拒否を引き起こす可能性がある。
3
v5.0.be-10.4.9
10.4.10
[修正, 10.3.1 から移動, レベル L1 > L3] アプリケーションに自動更新機能がある場合、更新はデジタル署名され、更新をインストールまたは実行する前にデジタル署名が検証されている必要がある。
3
v5.0.be-10.4.10
V15.4 同時並行性
競合状態、TOC/TOU 脆弱性、デッドロック、ライブロック、スレッド枯渇、不適切な同期などの同時並行性の問題は、予期しない動作やセキュリティリスクにつながる可能性があります。このセクションではこれらのリスクを緩和するためのさまざまな技法と戦略を説明します。
10.7.1
[修正, 1.11.3 から移動] マルチスレッドのコンテキストではスレッドセーフな型のみが使用されるか、スレッドセーフでない型が同期して競合状態を防いでいる。
3
v5.0.be-10.7.1
10.7.2
[修正, 1.11.2 から移動, レベル L2 > L3] 共有リソースへの同時アクセスは同期プリミティブ (ロック、ミューテックス、セマフォなど) を使用して制御され、競合状態を防ぎ、これらのリソースに対するアトミック操作を保証している。
3
v5.0.be-10.7.2
10.7.3
[修正, 11.1.6 から移動] 共有リソースへのすべてのアクセスは一貫してチェックされて、単一のアトミック操作でアクセスされ、Time-of-Check to Time-of-Use (TOCTOU) 競合状態を防ぎ、チェックと使用の間のリソース状態の一貫性を確保している。
3
v5.0.be-10.7.3
10.7.4
[追加] リソース取得では一貫したロック戦略を使用して循環依存関係を回避し、デッドロックとライブロックの両方のシナリオを防いで前進を確保している。
3
v5.0.be-10.7.4
10.7.5
[追加] リソース割り当てのポリシーは、スレッドプールを活用するなどしてリソースへの公平なアクセスを確保し、優先度の低いスレッドが妥当な時間枠内で処理を進められるようにすることで、スレッドの枯渇を防いでいる。
3
v5.0.be-10.7.5
10.7.6
[追加] ロックプリミティブは、所有するクラスまたはモジュールにのみアクセス可能で、パブリックに変更可能ではなく、ロックが外部のクラスやコードによって不注意にまたは悪意を持って変更できないようにしている。
3
v5.0.be-10.7.6
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?