Security Kit
HTTPヘッダーを通じてクロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）、クリックジャッキングのリスクを軽減し、SSL/TLSセキュリティを向上させる様々なセキュリティ強化オプションをDrupalに提供します。
seckit
インストール
composer require 'drupal/seckit:^2.0'
概要
Security Kitは、様々なHTTPセキュリティヘッダーとブラウザ側の保護機能を実装することで、DrupalウェブサイトのセキュリティポスチャーIを強化する包括的なセキュリティモジュールです。手動でサーバー設定を行うことなく、複数のセキュリティメカニズムを管理するための一元化された設定インターフェースを提供します。
このモジュールは、ブラウザがロードを許可されるリソースを制御するContent Security Policy（CSP）ヘッダーを実装し、多くのXSS攻撃を防止します。X-Frame-OptionsとJavaScriptベースのクリックジャッキング保護をサポートし、悪意のあるフレームにサイトが埋め込まれることを防ぎます。HTTP Strict Transport Security（HSTS）はブラウザにHTTPS接続の使用を強制し、Certificate Transparency（Expect-CT）は不正に発行された証明書の検出を支援します。
追加機能として、CSRF保護のためのOriginヘッダー検証、リファラー情報の漏洩を制御するReferrer-Policyヘッダー、ブラウザ機能を制限するFeature-Policyヘッダー、認証情報の露出を防ぐためのログインフォームのオートコンプリート無効化があります。また、ポリシー違反を監視するための組み込みCSP違反レポートエンドポイントも提供します。
Features
- default-src、script-src、style-src、img-srcなどを含む包括的なディレクティブをサポートするContent Security Policy（CSP）ヘッダー。レガシーブラウザサポートのためのベンダープレフィックス付きヘッダーもオプションで利用可能
- ブラウザのXSSフィルタリング動作を制御するX-XSS-Protectionヘッダー設定
- クリックジャッキング防止のためのX-Frame-Optionsヘッダー（SAMEORIGIN、DENY、ALLOW-FROM）
- 許可されていないフレームで表示された場合にページコンテンツを非表示にするJavaScript + CSS + Noscriptクリックジャッキング保護
- 設定可能なmax-age、サブドメイン包含、preloadサポートを備えたHTTP Strict Transport Security（HSTS）
- enforceモードと違反レポート機能を備えたCertificate Transparency（Expect-CT）ヘッダー
- カメラ、マイク、位置情報などのブラウザ機能へのアクセスを制御するFeature-Policyヘッダー
- 追加のクロスオリジン保護のためのFrom-Originヘッダー
- リファラー情報の露出を制御する複数のポリシーオプションを備えたReferrer-Policyヘッダー
- 設定可能なホワイトリストを使用したOriginヘッダー検証によるCSRF保護
- 認証情報のキャッシュを防ぐためのログインフォームオートコンプリート無効化
- Drupalのwatchdogに違反を記録する/report-csp-violationの組み込みCSP違反レポートエンドポイント
- ポリシーを強制せずにテストするためのCSPレポート専用モード
Use Cases
XSS防止のためのContent Security Policyの実装
信頼できるリソースソースをホワイトリストに登録するためにCSPを有効化します。まずレポート専用モードで開始し、ブロックされるリソースを特定し、/admin/reports/dblogでログを確認します。script-src 'self'などのディレクティブを設定して、自分のドメインからのスクリプトのみを許可します。インラインスクリプトにnonceやハッシュを使用して'unsafe-inline'を削除し、徐々にポリシーを厳格化します。
クリックジャッキング攻撃の防止
X-Frame-OptionsをSAMEORIGINまたはDENYで有効化し、悪意のあるサイトのフレームにサイトが埋め込まれるのを防ぎます。特定のパートナーによる埋め込みが必要なサイトでは、パートナーのオリジンを指定してALLOW-FROMを使用します。クリックジャッキングに対する多層防御のためにJavaScript + CSS + Noscript保護を有効化します。
HSTSによるHTTPSの強制
サイトがHTTPS経由で正しく動作することを確認した後、まず短いmax-age（例：300秒）でHSTSを有効化します。十分にテストしてから、max-ageを31536000（1年）に増やします。すべてのサブドメインがHTTPSをサポートしている場合はincludeSubDomainsを有効化します。サイトが常にHTTPSであることを確認してからのみpreloadを有効化し、hstspreload.orgに提出します。
セキュリティポリシー違反の監視
デフォルトの/report-csp-violationエンドポイントを使用してCSPをレポート専用モードで有効化します。違反はDrupalのwatchdogに記録されます。ログを定期的に確認して、ブロックされている正当なリソースと潜在的な攻撃の試みを特定します。本番環境の監視にはカスタムreport-uriを設定して外部レポートサービスを使用します。
認証情報盗難からの機密フォームの保護
オートコンプリート無効化機能を有効にして、ログインフォームや登録フォームに入力されたユーザー名とパスワードをブラウザがキャッシュしないようにします。これは共有コンピューターや公共端末で特に重要です。
リファラー情報の露出制御
Referrer-Policyをstrict-origin-when-cross-originで有効化し、同一オリジンリクエストと分析のためのリファラー情報を維持しながら、外部サイトへの完全なURLの漏洩を防ぎます。URLパスに機密情報が含まれる可能性がある非常に機密性の高いサイトにはno-referrerを使用します。
Tips
- ポリシーを強制する前に何がブロックされるかを理解するため、CSPはレポート専用モードで開始する
- ブラウザの開発者ツール（ネットワークタブ、コンソール）を使用して、セキュリティヘッダーが正しく送信されていることを確認する
- 別のドメインのiframeにサイトを埋め込もうとしてX-Frame-Optionsをテストする
- テスト時はHSTS max-ageを低く保ち、本番環境では少なくとも1年に増やす
- 'unsafe-inline' CSPディレクティブは保護を大幅に弱める - インラインスクリプトとスタイルの排除を試みる
- 必要なインラインスクリプトには'unsafe-inline'の代わりにCSP nonceまたはハッシュの使用を検討する
- 潜在的な攻撃を検出し、ホワイトリストに登録が必要な正当なリソースを特定するため、CSP違反ログを定期的に確認する
- Feature-Policyは新しいブラウザではPermissions-Policyに置き換えられている - ブラウザサポートを監視する
- securityheaders.comやMozilla Observatoryなどのオンラインツールを使用してセキュリティヘッダーをテストする
Technical Details
Admin Pages 1
/admin/config/system/seckit
すべてのSecurity Kitセキュリティ機能の中央設定ページ。管理者が様々なHTTPセキュリティヘッダーとブラウザ側の保護メカニズムを有効化・設定し、一般的なWeb脆弱性に対してDrupalインストールを強化できます。
権限 1
Troubleshooting 6
まず「レポート専用」オプションをチェックしてCSPをレポート専用モードで有効化します。/admin/reports/dblogのDrupalログでCSP違反レポートを確認し、どのリソースがブロックされているかを特定します。適切なディレクティブ（script-src、style-srcなど）に正当なリソースソースを追加します。一般的な問題には、'unsafe-inline'を必要とするインラインスクリプトや、明示的なオリジンホワイトリストが必要なサードパーティリソースが含まれます。
特定の外部サイトのiframeにサイトを埋め込む必要がある場合は、X-Frame-OptionsをDENYからALLOW-FROMに変更し、許可されるオリジンを指定します。ALLOW-FROMは単一のオリジンのみをサポートすることに注意してください。複数のオリジンの場合は、複数の値をサポートするCSP frame-ancestorsディレクティブの使用を検討してください。
max-ageが少なくとも31536000秒（1年）であること、includeSubDomainsが有効であること、HSTSヘッダーがHTTPS経由でルートドメインから提供されていることを確認します。これらの要件とすべてのサブドメインがHTTPSをサポートしていることを確認した後にのみ、hstspreload.orgにドメインを提出してください。
report-uriが/report-csp-violation（デフォルト）に設定されていることを確認します。このパスでサイトにアクセスできることを確認します。CSPが有効（強制またはレポート専用）であることを確認します。クロスオリジンレポートの場合は、サーバーログを確認してレポートエンドポイントがリクエストを受け入れることを確認します。
正当なオリジンを「許可されたオリジン」ホワイトリストに追加します。形式はプロトコルを含む完全なオリジン（例：https://trusted-site.com）にする必要があります。ホワイトリストエントリに末尾のスラッシュがないことを確認してください。
モジュールが有効で設定されていることを確認します。リバースプロキシやCDNがヘッダーを削除していないか確認します。一部のホスティング環境ではセキュリティヘッダーを上書きまたは削除する場合があります。ブラウザの開発者ツール（ネットワークタブ）を使用して、実際のレスポンスヘッダーを検査します。
Security Notes 8
- インストール時にサイト機能が壊れるのを防ぐため、すべてのセキュリティ機能はデフォルトで無効になっている - テスト後に意識的に機能を有効化する
- 'administer seckit'権限は「アクセス制限」としてマークされており、高度に信頼された管理者にのみ付与すべき
- CSPは設定を誤るとサイト機能を壊す可能性がある - 常にまずレポート専用モードでテストする
- preload付きHSTSは取り消しが困難 - 恒久的なHTTPSコミットメントを確認した後にのみ有効化する
- X-Frame-Options ALLOW-FROMはモダンブラウザでは非推奨 - より良いサポートのためにCSP frame-ancestorsを使用する
- OriginヘッダーCSRFチェックはすべてのブラウザで機能するわけではない - これは多層防御であり、主要なCSRF保護ではない
- オートコンプリートの無効化はパスワードマネージャーと競合する可能性がある - ユーザーエクスペリエンスへの影響を考慮する
- 一部のセキュリティヘッダーはサーバー設定やリバースプロキシによって上書きされる可能性がある - 送信される実際のヘッダーを確認する