現代のWebページは組織独自のJavaScriptのみで構築されているわけではありません。決済ページ、分析ツール、チャットウィジェット、A/Bテストシステム、広告タグ、決済SDKはそれぞれ複数のサードパーティスクリプトを読み込むことがあります。それらのスクリプトの一つでも侵害されると、ユーザーのブラウザで実行される悪意あるコードがWAAPの従来のリクエストレベルのコントロールを完全にバイパスできます。
特に決済フローにおいて、client-sideリスクは単なるベストプラクティスの問題ではなくなっています。PCI DSS 4.0 v4.0.1により、決済ページで実行されるスクリプトのコントロール、インベントリ、完全性がより重視されるようになりました。組織はどのソースがどのページで実行を許可されているかを実証できる必要があります。
アプリケーションチームにすべてのページへCSP、HSTS、フレーム保護、Referrer-Policyヘッダーを手動で追加させることは持続可能ではありません。レガシーアプリケーションではコード変更が困難であり、モダンアプリケーションでは異なるサービスチームが同じセキュリティ基準を一貫して適用しないこともあります。その結果、セキュリティヘッダーがあるページとないページが混在することになります。
正しいアプローチは、アプリケーションコードから独立して、ポリシー主導の立場からブラウザセキュリティヘッダーを一元的に適用することです。ADCはレスポンスヘッダーを書き換えて、CSP、HSTS、クリックジャッキング保護、MIMEスニッフィング防止、Referrerコントロール、フィンガープリントクリーンアップを標準化すべきです。
TR7 Client-Side Script Protectionはこのモデルを提供します。vServiceレベルでclient-sideリスクに対する基本的なセキュリティヘッダーを適用し、ブラウザセキュリティを中央WAAPポリシーに結びつけます。
TR7はレスポンスヘッダーの書き換え、CSPプロファイル、フィンガープリントクリーンアップ、コンプライアンス可視化を通じてclient-sideスクリプト保護を実装します。
TR7はset-headerまたはadd-headerの動作を使用してHTTPレスポンスフェーズ中にセキュリティヘッダーを適用します。アプリケーションコードや証明書の構造を変更することなくブラウザセキュリティコントロールを有効化できます。
Content-Security-Policyヘッダーは許可されたソースモデルをブラウザに伝えます。TR7は現在、固定の`default-src 'self';`アプローチによるベースラインCSP保護を提供します。
Server、X-Powered-By、X-AspNet-Version、X-AspNetMvc-Versionなどのヘッダーをレスポンスから除去できます。これにより攻撃者が技術インベントリを構築してCVEを照合することが困難になります。
securityHeadersルールが有効なvServiceをコンプライアンスレポートの証拠として提示できます。これにより決済ページセキュリティとclient-sideコントロールプロセスの監査証跡が強化されます。
Client-Side Script Protectionは単一のsecurityHeadersルールの下に8つの既製セキュリティヘッダーを適用します。
TR7はsecurityHeadersルールを通じてContent-Security-Policyヘッダーを追加できます。現在の動作では`default-src 'self';`によるベースラインセキュリティポリシーが生成されます。このポリシーは同一オリジンのリソースのみを受け入れるブラウザのデフォルトを目指します。より複雑なCSP要件はカスタムヘッダー設定またはアプリケーション側の変更で対処すべきです。
Strict-Transport-SecurityヘッダーはTLS接続に適用できます。該当ドメインでHTTPSを要求するようブラウザに指示します。includeSubDomainsやpreloadなどのオプションにより、より厳格なセキュリティ動作が実現します。HSTSはHTTPのみのホストに誤ったポリシーが発行されないようTLSコンテキストにのみ適用されます。
X-Frame-OptionsヘッダーはSAMEORIGIN値で適用できます。これにより異なるオリジンのiframe内でページが読み込まれることを制限します。特にログイン、決済、管理パネル、機密トランザクションページでのクリックジャッキングリスク軽減に役立ちます。ユーザーインターフェースリドレス攻撃に対する低コストのベースライン保護を提供します。
X-Content-Type-OptionsヘッダーはnosniffValuで追加できます。これによりブラウザがコンテンツタイプを推測して予期しない形式でコンテンツを実行することを防ぎます。このコントロールは特にファイルアップロードフロー、静的コンテンツ、不正なコンテンツタイプを返すレガシーアプリケーションで価値があります。MIME混同によるclient-sideリスクが軽減されます。
Referrer-Policyヘッダーはno-referrer-when-downgradeのデフォルトで適用できます。これによりHTTPSからHTTPへの遷移などのシナリオでReferrer漏洩を制限します。市民・顧客・セッションパラメーターを含むURLではReferrerの動作が重要です。組織はブラウザが外部サイトに運ぶソースURL情報の量を一元的に制限できます。
Permission-Policyヘッダーはマイクロフォン、カメラ、位置情報などのブラウザ機能へのアクセスを制限するために使用できます。TR7はsecurityHeadersルールの下にこのヘッダーを適用し、不要なブラウザ権限の攻撃面を縮小します。特にポータル、決済、管理画面では、ページが予期しないAPIにアクセスすることを防ぎます。client-sideセキュリティはスクリプトオリジンのみに限定されません。
X-XSS-Protectionヘッダーはモダンブラウザでは効果が限定されますが、古いクライアントとの互換性のために使用できます。`1; mode=block`の動作は一部のレガシーブラウザで基本的なXSSフィルターを有効化します。このヘッダー単体でセキュリティを保証するものではなく、CSPおよびWAAPコントロールと合わせて検討すべきです。レガシーユーザーベースを持つ組織に低コストの追加の層を提供します。
TR7はServer、X-Powered-By、X-AspNet-Version、X-AspNetMvc-Versionなどのヘッダーを削除できます。これらのヘッダーは使用中のアプリケーションサーバー、フレームワーク、ランタイムバージョンのヒントになる場合があります。攻撃者はこの情報をCVEの照合やターゲット型エクスプロイトの試みに利用できます。フィンガープリントクリーンアップは可視の攻撃面を縮小する実践的なハードニングステップです。
securityHeadersは特定のvService、ドメイン、パス条件にルールタイプとしてバインドできます。決済ページはより厳格なセットで、内部ポータルは別のセットで、レガシーアプリケーションはより緩やかな組み合わせで実行できます。これにより単一のグローバルヘッダーポリシーがアプリケーションを壊すことを防ぎます。オペレーターはサービスコンテキストに応じてセキュリティヘッダーを適用します。
TR7はclient-sideスクリプト保護の現在のスコープをレスポンスヘッダー層で実装します。追加のJavaScriptエージェント、クライアントSDK、別のリバースプロキシは必要ありません。このアプローチは低レイテンシーと広範な互換性を提供します。現在の実際の機能はセキュリティヘッダーの標準化であり、ランタイムのスキマー検出や自動SRI注入は含まれません。
securityHeadersルールが有効なvServiceをコンプライアンスレポートに提示できます。これにより決済ページセキュリティヘッダーがどこで適用されているかを監査担当者と共有しやすくなります。PCI DSS 4.0 v4.0.1セクション6.4.3のclient-sideセキュリティ要件に対する技術的証拠の作成をサポートします。レポートによりヘッダーポリシーが設定されているだけでなく、どのサービスで有効であるかが可視化されます。
ボット保護やアクセスブロッキングのためにカスタムHTMLページが返される場合も、同じレスポンスパスでセキュリティヘッダーを維持できます。これによりエラーやチャレンジページがメインアプリケーションよりも弱いセキュリティヘッダーで返されることを防ぎます。ユーザーに提示されるすべてのレスポンスが同一のベースラインブラウザセキュリティ基準に近づきます。ログインとボット検証フローでは一貫性が特に重要です。
Client-sideスクリプト保護は、レスポンスヘッダーの順序、HSTS条件、固定CSP動作、securityHeadersルールタイプ、フィンガープリントクリーンアップにまたがって動作します。
TR7はset-headerで一部のヘッダーを上書きし、add-headerで他のヘッダーを追加できます。この違いにより既存のアプリケーションヘッダーがどのように動作するかが決まります。本番環境に移行する前に、アプリケーション独自のヘッダーがTR7が追加するヘッダーと競合しないかテストすることをお勧めします。
HSTSはTLS接続にのみ適用すべきです。TR7はHTTPのみのホストが誤ったHSTSヘッダーを受け取らないよう、このヘッダーをssl_fc条件に関連付けます。不正なHSTSポリシーは一部のドメインでアクセス問題を引き起こす可能性があるため、注意して使用すべきです。
現在のsecurityHeadersの動作でCSPを有効にすると、`default-src 'self';`ヘッダーが固定値として生成されます。このページの有効な機能内には追加のカスタムディレクティブエディターはありません。より詳細なCSP要件については、カスタムヘッダールールまたはアプリケーション側の設定を計画すべきです。
securityHeadersはWAAPシグネチャスコアリングルールのようには機能しません。常に適用されるレスポンスヘッダーハードニングルールとして扱われます。そのため攻撃スコアやしきい値の結果にバインドされていません。
Server、X-Powered-By、X-AspNet-Version、X-AspNetMvc-Versionヘッダーを削除できます。これらのヘッダーを削除してもアプリケーションの動作は変わりません。外部への技術情報の可視性が低下するだけです。レガシーアプリケーションでは、このシンプルなステップが情報漏洩を意味のある形で低減できます。
CSPとフレームポリシーは一部のアプリケーションコンポーネントに影響を与えることがあります。インラインスクリプトを使用したり外部ソースからコンテンツを読み込んだりするページは特に、テスト環境で最初に検証すべきです。TR7のルールベースのアプローチにより、広範にロールアウトする前に限定されたパスまたはドメインで厳格なポリシーを試すことが簡単になります。
ECサイトチームはチェックアウトページのvServiceレベルでCSP、HSTS、サーバーフィンガープリントクリーンアップを有効化できます。このセットアップによりPCI DSS 4.0 v4.0.1のclient-sideセキュリティコントロールに対するレポート可能な技術的証拠が生成されます。
銀行ポータルはX-Frame-Options SAMEORIGINとPermission-Policyを使用して、不正なiframe埋め込みと不要なブラウザAPIアクセスを制限できます。ログインとトランザクションページのclient-side攻撃面が縮小されます。
公共部門アプリケーションは機密URL情報を含むページにReferrer-Policyを適用できます。市民のセッションやトランザクションコンテキストに紐付いたURLフラグメントが外部サイトに運ばれるリスクが低減されます。
古い.NETや類似のアプリケーションでは、Server、X-Powered-By、フレームワークバージョンのヘッダーが外部に漏洩することがあります。TR7はこれらのヘッダーを削除し、攻撃者が技術インベントリを構築することを困難にします。
SaaSプロバイダーは各テナントのvServiceに異なるsecurityHeaders組み合わせを適用できます。B2Bテナントはコンプライアンス要件が許す範囲でより緩やかなポリシーで運用でき、B2Cフローはより厳格なヘッダーセットを使用できます。
CSP、HSTS、クリックジャッキング保護、サーバーフィンガープリントクリーンアップ — 単一のポリシーから、アプリケーションコードに触れることなく。お客様自身のサービスでのライブセットアップをご案内します。