> For the complete documentation index, see [llms.txt](https://coky-t.gitbook.io/owasp-asvs-ja/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coky-t.gitbook.io/owasp-asvs-ja/owasp-apurikshonsekyuriti-40/0x22-v14-config.md). # V14: 構成 ## 管理目標 検証対象のアプリケーションが以下を備えていることを確認します。 * セキュアで、再現性があり、自動化されたビルド環境。 * 古くなったコンポーネントやセキュアでないコンポーネントがアプリケーションに含まれないような、堅牢なサードパーティライブラリ、依存関係、構成管理。 箱から出してすぐのアプリケーションの構成はインターネット上で安全であるべきです。つまり、そのままで安全な構成であるということです。 ## V14.1 ビルドとデプロイ ビルドパイプラインはリピート可能なセキュリティの基盤です。セキュアではないものが発見されるたびに、ソースコード、ビルド、またはデプロイメントスクリプトで解決され、自動的にテストされます。既知のセキュリティ問題が本番環境にデプロイされることを防ぐために、ビルドを警告または中断する自動セキュリティおよび依存関係チェックを備えたビルドパイプラインの使用を強くお勧めします。手動で不規則に実行された手順は回避できないセキュリティ上の誤りに直接つながります。 業界が DevSecOps モデルに移行するにつれて、「既知の良好な」状態を達成するために、デプロイメントと構成の継続的な可用性と完全性を確保することが重要です。これまで、システムがハックされた場合、それ以上の侵入が行われていないことを証明するのに数日から数か月かかりました。今日では、ソフトウェア定義のインフラストラクチャ、ダウンタイムゼロでの迅速な A/B デプロイメント、自動コンテナ化ビルドの出現により、危殆化されたシステムに代わる「既知の良好な」代替品を自動的かつ継続的に構築、堅牢化、デプロイできます。 従来のモデルがまだ存在している場合は、手動で手順を実行してその構成を堅牢化およびバックアップし、危殆化されたシステムをタイムリーに完全性が高く危殆化されていないシステムに迅速に置き換えることができる必要があります。 このセクションに準拠するには自動ビルドシステムと、ビルドおよびデプロイメントスクリプトへのアクセスが必要です。 | # | 説明 | L1 | L2 | L3 | CWE | | :--------: | ------------------------------------------------------------------------------------------------------------------------ | :-: | :-: | :-: | :-: | | **14.1.1** | アプリケーションのビルドおよびデプロイメントプロセスが、CI / CD 自動化、自動構成管理、自動デプロイメントスクリプトなど、セキュアでリピート可能な方法で実行されている。 | | ✓ | ✓ | | | **14.1.2** | スタックのランダム化、データ実行防止など、利用可能なすべてのバッファオーバーフロー保護および警告を有効にし、安全ではないポインタ、メモリ、書式文字列、整数、文字列操作が見つかった場合にはビルドを中止するようにコンパイラフラグを設定している。 | | ✓ | ✓ | 120 | | **14.1.3** | 使用しているアプリケーションサーバおよびフレームワークの推奨に従い、サーバ構成が堅牢化されている。 | | ✓ | ✓ | 16 | | **14.1.4** | アプリケーション、構成、およびすべての依存関係が、文書化およびテストされた Runbook から作成された自動デプロイメントスクリプトを使用して遅延なく再デプロイできること、またはバックアップからタイムリーにリストアできる。 | | ✓ | ✓ | | | **14.1.5** | 改竄を検出するために、許可された管理者がすべてのセキュリティ関連構成の完全性を検証できる。 | | | ✓ | | ## V14.2 依存関係 依存関係管理はあらゆる種類のアプリケーションを安全に運用するために不可欠です。古い依存関係やセキュアでない依存関係で最新に保てないことが、これまでで最大かつ最高となる攻撃の根本原因です。 注意: レベル 1 では、14.2.1 順守はより正確なビルド時の静的コード解析や依存関係解析よりも、クライアント側および他のライブラリやコンポーネントの監視や検出に関連します。これらのより正確なテクニックは、必要に応じてインタビューにより発見可能です。 | # | 説明 | L1 | L2 | L3 | CWE | | :--------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :--: | | **14.2.1** | できれば依存関係チェッカーをビルド時またはコンパイル時に使用して、すべてのコンポーネントが最新である。 ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 1026 | | **14.2.2** | すべての不要な機能、ドキュメント、サンプルアプリケーション、構成が削除されている。 | ✓ | ✓ | ✓ | 1002 | | **14.2.3** | JavaScript ライブラリ、CSS 、Web フォントなどのアプリケーション資産がコンテンツ配信ネットワーク (Content Delivery Network, CDN) や外部のプロバイダで外部的にホストされている場合には、サブリソース完全性 (Subresource Integrity, SRI) を使用して資産の完全性を確認している。 | ✓ | ✓ | ✓ | 829 | | **14.2.4** | サードパーティコンポーネントは事前定義済みで信頼でき、継続的に保守されているリポジトリから取得している。 ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 829 | | **14.2.5** | 使用しているすべてのサードパーティライブラリのソフトウェア部品表 (SBOM) が保守されている。 ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | | **14.2.6** | アプリケーションに必要な動作のみを開示するためにサードパーティライブラリをサンドボックス化またはカプセル化することでアタックサーフェスが減少している。 ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 | ## V14.3 意図しないセキュリティ開示 デバッグコンソールなどの一般的な攻撃からの保護、クロスサイトスクリプティング (Cross-site Scripting, XSS) およびリモートファイルインクルージョン (Remote File Inclusion, RFI) 攻撃に対するハードルの引き上げ、そして多くのペネトレーションテストレポートの歓迎されない品質証明である厄介な情報露見「脆弱性」を排除するために、プロダクションの設定を堅牢化すべきです。これらの問題の多くは重大なリスクとみなされることはめったにありませんが、それらは他の脆弱性と連鎖しています。これらの問題がデフォルトで現れなければ、それはほとんどの攻撃が成功する前にハードルを引き上げます。 | # | 説明 | L1 | L2 | L3 | CWE | | :--------: | ------------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :-: | | **14.3.1** | \[削除, 7.4.1 と重複] | | | | | | **14.3.2** | デバッグ機能、開発者コンソール、意図しないセキュリティ開示を排除するために、Web またはアプリケーションサーバおよびアプリケーションフレームワークのデバッグモードが本番環境で無効になっている。 | ✓ | ✓ | ✓ | 497 | | **14.3.3** | HTTP ヘッダまたは HTTP レスポンスの一部がシステムコンポーネントの詳細なバージョン情報を開示していない。 | ✓ | ✓ | ✓ | 200 | ## V14.4 HTTP セキュリティヘッダ | # | 説明 | L1 | L2 | L3 | CWE | | :--------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :--: | | **14.4.1** | すべての HTTP レスポンスに Content-Type ヘッダが含まれている。またコンテンツタイプが text/\*, /+xml および application/xml の場合には安全な文字セット (UTF-8, ISO-8859-1 など) を指定する。コンテンツは提供された Content-Type ヘッダと一致する必要がある。 | ✓ | ✓ | ✓ | 173 | | **14.4.2** | すべての API レスポンスに Content-Disposition: attachment; filename="api.json" ヘッダ (またはコンテンツタイプに適したその他のファイル名) が含まれている。 | ✓ | ✓ | ✓ | 116 | | **14.4.3** | HTML, DOM, JSON, JavaScript インジェクション脆弱性などの XSS 攻撃に対する影響を軽減するのに役立つコンテンツセキュリティポリシー (Content Security Policy, CSP) レスポンスヘッダが設定されている。 | ✓ | ✓ | ✓ | 1021 | | **14.4.4** | すべてのレスポンスに X-Content-Type-Options: nosniff ヘッダが含まれている。 | ✓ | ✓ | ✓ | 116 | | **14.4.5** | Strict-Transport-Security ヘッダが、Strict-Transport-Security: max-age=15724800; includeSubdomains のように、すべてのレスポンスとすべてのサブドメインに含まれている。 | ✓ | ✓ | ✓ | 523 | | **14.4.6** | URL 内の機密情報が Referer ヘッダを介して信頼できない関係者に公開されないように、適切な Referrer-Policy ヘッダが含まれている。 | ✓ | ✓ | ✓ | 116 | | **14.4.7** | Web アプリケーションのコンテンツはデフォルトでサードパーティのサイトに埋め込むことができない、および適切な Content-Security-Policy: frame-ancestors と X-Frame-Options レスポンスヘッダを使用して必要な場所でのみ正規のリソースの埋め込みが許可されている。 | ✓ | ✓ | ✓ | 1021 | ## V14.5 HTTP リクエストヘッダバリデーション | # | 説明 | L1 | L2 | L3 | CWE | | :--------: | --------------------------------------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :-: | | **14.5.1** | アプリケーションサーバが、アプリケーションや API によって使用されている HTTP メソッドのみ (pre-flight OPTIONS を含む) を受け入れ、アプリケーションコンテキストに対する無効な要求についてログ出力やアラート発行する。 | ✓ | ✓ | ✓ | 749 | | **14.5.2** | Origin ヘッダは攻撃者によって簡単に変更される可能性があるため、提供された Origin ヘッダが認証またはアクセス制御判定に使用されていない。 | ✓ | ✓ | ✓ | 346 | | **14.5.3** | クロスオリジンリソース共有 (CORS) Access-Control-Allow-Origin ヘッダが信頼できるドメインおよびサブドメインの厳密な許可リストを使用して照合し、"null" オリジンをサポートしていない。 | ✓ | ✓ | ✓ | 346 | | **14.5.4** | 信頼できるプロキシまたは SSO デバイスにより追加されたベアラトークンなどの HTTP ヘッダがアプリケーションにより認証されている。 | | ✓ | ✓ | 306 | ## 参考情報 詳しくは以下の情報を参照してください。 * [OWASP Web Security Testing Guide 4.1: Testing for HTTP Verb Tampering](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.html) * API レスポンスに Content-Disposition を追加すると、クライアントとサーバ間の MIME タイプの理解の相違に基づく多くの攻撃を防ぐことができます。また "filename" オプションは [反射型ファイルダウンロード攻撃](https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf) を防ぐのに役立ちます。 * [Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) * [Exploiting CORS misconfiguration for BitCoins and Bounties](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) * [OWASP Web Security Testing Guide 4.1: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.html) * [Sandboxing third party components](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content)