V3: Web フロントエンドセキュリティ
管理目標
このカテゴリは Web フロントエンドを介して実行される攻撃から保護する要件に焦点を当てています。これらの要件はマシン間ソリューションには適用されません。
V3.1 Web フロントエンドセキュリティドキュメント
このセクションではアプリケーションのドキュメントに指定する必要があるブラウザのセキュリティ機能について概説します。
3.1.1
アプリケーションドキュメントには、アプリケーションを使用するブラウザがサポートする必要がある想定されるセキュリティ機能 (HTTPS、HTTP Strict Transport Security (HSTS)、コンテンツセキュリティポリシー (CSP)、その他の関連する HTTP セキュリティメカニズムなど) を記載している。これらの機能の一部が利用できない場合にアプリケーションがどのように動作しなければならないか (ユーザへの警告やアクセスのブロックなど) も定義する必要がある。
3
V3.2 意図しないコンテンツ解釈
コンテンツや機能を不適切なコンテンツでレンダリングすると、悪意のあるコンテンツが実行または表示される可能性があります。
3.2.1
ブラウザが不正なコンテキスト (API、ユーザがアップロードしたファイル、または他のリソースが直接リクエストされる場合など) で HTTP レスポンスのコンテンツや機能をレンダリングすることを防ぐために、セキュリティ制御が行われている。可能な制御には、HTTP リクエストヘッダフィールド (Sec-Fetch-* など) が正しいコンテキストであることを示さない限りコンテンツを提供しないこと、Content-Security-Policy ヘッダフィールドの sandbox ディレクティブを使用するか、Content-Disposition ヘッダフィールドの attachment ディポジションタイプを使用することなどがある。
1
3.2.2
HTML としてレンダリングするのではなく、テキストとして表示することを意図したコンテンツは、HTML や JavaScript などのコンテンツの意図しない実行を防ぐために、安全なレンダリング関数 (createTextNode や textContent など) を使用して処理している。
1
3.2.3
アプリケーションは、明示的な変数宣言の採用、厳密な型チェックの実行、document オブジェクトへのグローバル変数の保存の回避、名前空間分離の実装によって、クライアントサイド JavaScript を使用する際の DOM clobbering を回避している。
3
V3.3 クッキーセットアップ
このセクションでは、機密性の高いクッキーがアプリケーション自体によって作成されたことをより確実にし、その内容が漏洩したり不適切に変更されることを防ぐために、機密性の高いクッキーを安全に構成するための要件について概説します。
3.3.1
クッキーには 'Secure' 属性が設定されており、クッキー名に '__Host-' プレフィックスが使用されていない場合は、クッキー名に '__Secure-' プレフィックスを使用する必要がある。
1
3.3.2
各クッキーの 'SameSite' 属性値はクッキーの目的に応じて設定され、一般にクロスサイトリクエストフォージェリ (CSRF) として知られる、ユーザーインタフェースのリドレス攻撃やブラウザベースのリクエストフォージェリ攻撃への露出を制限している。
2
3.3.3
クッキーは、明示的に他のホストと共有するように設計されていない限り、クッキー名に '__Host-' プレフィックスを付けている。
2
3.3.4
クッキーの値がクライアントサイドスクリプトからアクセスされることを意図していない場合 (セッショントークンなど)、クッキーは 'HttpOnly' 属性が設定される必要があり、同じ値 (セッショントークンなど) は 'Set-Cookie' ヘッダフィールドを介してのみクライアントに転送される必要がある。
2
3.3.5
アプリケーションがクッキーを書き込む際、クッキー名と値を合わせた長さは 4096 バイトを超えない。大きすぎるクッキーはブラウザに保存されないため、リクエストとともに送信されず、ユーザはそのクッキーに依存するアプリケーション機能を使用できなくなる。
3
V3.4 ブラウザのセキュリティメカニズムヘッダ
このセクションでは、アプリケーションからのレスポンスを処理する際にブラウザのセキュリティ機能と制限を有効にするために、HTTP レスポンスに設定する必要があるセキュリティヘッダについて説明します。
3.4.1
HTTP Strict Transport Security (HSTS) ポリシーを適用するために、Strict-Transport-Security ヘッダフィールドがすべてのレスポンスに含まれている。少なくとも 1 年間の最大有効期間を定義する必要があり、L2 以上では、ポリシーをすべてのサブドメインにも適用する必要がある。
1
3.4.2
クロスオリジンリソース共有 (CORS) Access-Control-Allow-Origin ヘッダフィールドがアプリケーションによって固定値にしている。または、Origin HTTP リクエストヘッダフィールド値が使用される場合は、信頼できるオリジンの厳密な許可リストに対して検証されている。'Access-Control-Allow-Origin: *' を使用する必要がある場合、レスポンスに機密情報が含まれていない。
1
3.4.3
HTTP レスポンスには Content-Security-Policy ヘッダフィールドを含み、悪意のある JavaScript の実行を制限するために、ブラウザが信頼できるコンテンツやリソースのみをロードして実行するようにディレクトリを定義している。少なくとも、ディレクティブ object-src 'none' および base-uri 'none' を含み、許可リストを定義するか、ナンスまたはハッシュを使用するグローバルポリシーを使用する必要がある。L3 アプリケーションでは、ナンスまたはハッシュを用いたレスポンスごとのポリシーを定義する必要がある。
2
3.4.4
すべての HTTP レスポンスには 'X-Content-Type-Options: nosniff' ヘッダフィールドを含んでいる。これは、与えられたレスポンスに対してコンテンツスニッフィングと MIME タイプ推測を使用しないようにブラウザに指示し、レスポンスの Content-Type ヘッダフィールド値が宛先リソースと一致することを要求します。たとえば、スタイルに対するリクエストへのレスポンスは、レスポンスの Content-Type が 'text/css' である場合にのみ受け入れられる。また、これによりブラウザの Cross-Origin Read Blocking (CORB) 機能の使用も可能にする。
2
3.4.5
アプリケーションは 'Referer' HTTP リクエストヘッダフィールドを介して、技術的に機密データがサードパーティサービスに漏洩することを防ぐために、リファラポリシーを設定している。これは Referrer-Policy HTTP レスポンスヘッダフィールドを使用するか、HTML 要素属性を介して使用して行うことができる。機密データは URL 内のパスやクエリデータ、そして内部の非公開アプリケーションではホスト名も含むことがある。
2
3.4.6
Web アプリケーションはすべての HTTP レスポンスに対して Content-Security-Policy ヘッダフィールドの frame-ancestors ディレクティブを使用して、デフォルトでは埋め込むことができないようにし、特定のリソースの埋め込みは必要な場合にのみ許可されるようにしている。X-Frame-Options ヘッダフィールドは、ブラウザによってサポートされているが、廃止されており、信頼できないことに注意する。
2
3.4.7
Content-Security-Policy ヘッダフィールドが違反を報告する場所を指定している。
3
3.4.8
ドキュメントのレンダリングを開始するすべての HTTP レスポンス (Content-Type text/html のレスポンスなど) には、必要に応じて、same-origin ディレクティブまたは the same-origin-allow-popups ディレクティブを持つ Cross‑Origin‑Opener‑Policy ヘッダフィールドを含んでいる。これにより、タブナビングやフレームカウンティングなど、Window オブジェクトへの共有アクセスを悪用する攻撃を防いでいる。
3
V3.5 ブラウザのオリジン分離
サーバサイドで機密機能へのリクエストを受け入れる場合、アプリケーションはそのリクエストがアプリケーション自体あるいは信頼できるパーティによって開始され、攻撃者によって偽造されていないことを確認する必要があります。
このコンテキストにおける機密機能には、認証されたユーザと認証されていないユーザのフォーム投稿の受け入れ (認証リクエストなど)、状態変更操作、リソース要求機能 (データエクスポートなど) があります。
ここでの重要な保護は JavaScript の Same Origin Policy やクッキーの SameSite ロジックなどのブラウザセキュリティポリシーです。もう一つの一般的な保護は CORS プリフライトメカニズムです。このメカニズムは、異なるオリジンから呼び出されるように設計されたエンドポイントにとって重要ですが、異なるオリジンから呼び出されるように設計されていないエンドポイントにとっても、リクエストフォージェリ防止メカニズムとして役立ちます。
3.5.1
アプリケーションが、機密機能を使用するための、許可されていないクロスオリジンリクエストを防ぐために、CORS プリフライトメカニズムに依存していない場合、これらのリクエストを検証して、アプリケーション自体から発信したものであることを確認している。これはフォージェリ防止トークンを使用して検証するか、CORS セーフリストリクエストヘッダフィールドではない追加の HTTP ヘッダフィールドを要求することで行われる。これは、一般にクロスサイトリクエストフォージェリ (CSRF) と呼ばれる、ブラウザベースのリクエストフォージェリ攻撃を防御するためのものである。
1
3.5.2
アプリケーションが、機密機能の許可されていないクロスオリジン使用を防ぐために、CORS プリフライトメカニズムに依存している場合、CORS プリフライトリクエストをトリガーしないリクエストで機能を呼び出すことはできない。これは 'Origin' および 'Content-Type' リクエストヘッダフィールドの値をチェックするか、CORS セーフリストのヘッダフィールドではない追加のヘッダフィールドを使用する必要があるかもしれない。
1
3.5.3
機密機能の HTTP リクエストは POST, PUT, PATCH, DELETE などの適切な HTTP メソッドを使用し、HEAD, OPTIONS, GET などの HTTP 仕様で「安全」と定義されているメソッドを使用しない。あるいは、Sec-Fetch-* リクエストヘッダフィールドの厳密なバリデーションを使用して、不適切なクロスオリジンコール、ナビゲーションリクエスト、期待されていないリソースロード (画像ソースなど) からリクエストが発生していないことを確保している。
1
3.5.4
あるオリジンでロードされたドキュメントやスクリプトが別のオリジンのリソースとやり取りする方法や、クッキーのホスト名制限など、同一オリジンポリシーによって提供される制限を活用するために、別のアプリケーションは異なるホスト名でホストされている。
2
3.5.5
メッセージのオリジンが信頼できない場合、またはメッセージの構文が無効な場合、postMessage インタフェースによって受信したメッセージを破棄している。
2
3.5.6
クロスサイトスクリプトインクルージョン (XSSI) 攻撃を避けるために、JSONP 機能はアプリケーションのどの部分でも有効になっていない。
3
3.5.7
クロスサイトスクリプトインクルージョン (XSSI) 攻撃を防ぐために、認可が必要なデータは JavaScript ファイルなどのスクリプトリソースレスポンスには含まれていない。
3
3.5.8
認証されたリソース (画像、動画、スクリプト、その他のドキュメントなど) は、意図した場合にのみユーザの代わりにロードまたは埋め込むことができる。これは、Sec-Fetch-* HTTP リクエストヘッダフィールドの厳密なバリデーションにより、リクエストが不適切なクロスオリジンコールから生じたものではないことを確保するか、制限的な Cross-Origin-Resource-Policy HTTP レスポンスヘッダフィールドを設定することにより、ブラウザが返されたコンテンツをブロックするように指示することで実現できる。
3
V3.6 外部リソース完全性
このセクションではサードパーティのサイトでコンテンツを安全にホストするためのガイダンスを提供します。
3.6.1
JavaScript ライブラリ、CSS、Web フォントなどのクライアントサイド資産は、リソースが静的かつバージョン管理されており、サブリソース完全性 (Subresource Integrity, SRI) を使用して資産の完全性を検証している場合にのみ、外部 (コンテンツ配信ネットワーク (Content Delivery Network) など) にホストされている。これが不可能な場合は、各リソースについて、この正当性を証明するセキュリティ上の決定事項を文書化する必要がある。
3
V3.7 ブラウザのセキュリティに関するその他の考慮事項
このセクションではクライアントサイドのブラウザセキュリティに必要となるその他のさまざまなセキュリティコントロールや最新のブラウザセキュリティ機能を含みます。
3.7.1
アプリケーションは依然としてサポートされており安全であると考えられているクライアントサイドのテクノロジのみを使用している。この要件を満たさないテクノロジの例としては NSAPI プラグイン、Flash、Shockwave、ActiveX、Silverlight、NACL、クライアントサイド Java アプレットなどがある。
2
3.7.2
アプリケーションは、宛先が許可リストに記載されている別のホスト名やドメイン (アプリケーションで制御されていない) にのみユーザーを自動的にリダイレクトしている。
2
3.7.3
ユーザがアプリケーションの制御外の URL にリダイレクトされる場合、アプリケーションはナビゲーションをキャンセルするオプションとともに通知を表示している。
3
3.7.4
アプリケーションのトップレベルドメイン (例: site.tld) が HTTP Strict Transport Security (HSTS) のパブリックプリロードリストに追加されている。これにより、アプリケーションの TLS の使用が、Strict-Transport-Security レスポンスヘッダフィールドのみに依存するのではなく、メインブラウザに直接組み込まれるようになる。
3
3.7.5
アプリケーションへのアクセスに使用されるブラウザが、想定されるセキュリティ機能をサポートしていない場合、アプリケーションはドキュメントに記載されているとおりに動作する (ユーザへの警告やアクセスのブロックなど)。
3
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?