HTTPセキュリティヘッダー：CSP・HSTSの確認方法

アプリケーションをデプロイしました。ページは読み込まれ、フォームは機能し、何も壊れているようには見えません。次にスキャンを実行すると、次の結果のリストが返されます。 ヘッダー - そしてそれはどれも明らかではありません。

それは正常な最初の反応です。ヘッダーは画面上に表示されないため、ヘッダーが重要なのか、それとも単にスキャナーが問題を起こしているだけなのかを判断するのは困難です。このガイドでは、最も頻繁に表示されるヘッダー、各ヘッダーの実際の機能、および推測に頼らずにヘッダーを確認する方法について説明します。

セキュリティ ヘッダーは、サーバーがページと一緒にブラウザーに送信する指示です。ブラウザはそれらを読み取り、コンテンツの処理方法を調整します。つまり、どのスクリプトを実行できるか、ページをプレーン HTTP 上にロードできるかどうか、別のサイトがフレームに埋め込めるかどうかなどです。

ページ上の何も変更はありません。まさにこれが、これらの調査結果が抽象的に感じられる理由です。サイトは、何か問題が発生した日に問題となる一連の保護機能を欠いていながらも、見た目も動作も完璧です。

正直な枠組みは次のとおりです。ヘッダーは特定の種類のリスクを軽減します。それら自体ではサイトが安全になるわけではなく、クリーンなヘッダー チェックはサイトが完全に安全であることを証明するものではありません。それらは、複数のレイヤーの中の 1 つであり、正しく作成するのに最も安価なレイヤーの 1 つであると考えてください。

ブラウザがページをリクエストすると、サーバーはそのページで応答します。 そして 応答ヘッダーと呼ばれるメタデータのブロック。これらは自分で見ることができます。ブラウザの開発者ツールを開き、[ネットワーク] タブに移動し、ページをリロードして、一番上のリクエストをクリックします。ヘッダーはすぐそこにあります。

セキュリティ ヘッダーは、ブラウザーにルールを強制するよう指示するものにすぎません。厳密なものもあれば、勧告的なものもあり、それらはすべて、HTML ではなく、サーバー構成、フレームワーク、またはホスティング プラットフォームで設定されます。

CSP は、ページへのロードを許可するコンテンツ ソースをブラウザーに指示します。これはここで最も強力なヘッダーであり、人々が最も威圧的だと感じるヘッダーです。

実際には、CSP には次のような内容が記載されています。スクリプトは独自のドメインと 1 つの信頼できる CDN からのみ取得できます。画像は HTTPS 以降のどこからでも取得できます。ページが他のサイトによってフレーム化されることはできません。許可していないソースから何かを読み込もうとすると、ブラウザはそれをブロックし、その試みをコンソールに記録します。

CSP は、安全な出力エンコードとサニタイズに加えて、スクリプト インジェクションに対する追加の防御策です。また、あまりにも積極的に設定すると、何かが壊れる可能性が最も高いヘッダーでもあります。初心者にとって実際的な方法は、レポートのみのモードで開始し、何がブロックされるかを監視し、実際の問題を修正してから、それを強制することです。

HSTS は、定義された期間、HTTPS 経由でのみサイトと通信するようにブラウザーに指示します。ブラウザがこのヘッダーを認識すると、ユーザーが次のように入力しても、ドメインへの安全でない HTTP 接続を確立することを拒否します。 http:// または古いリンクをたどります。

ブラウザが HSTS ポリシーを認識すると、HTTP リクエストを送信する前にアップグレードします。ドメインがすでに HSTS プリロード エントリでカバーされていない限り、最初の訪問でも HTTP を使用できます。

ここで尊重すべきことは、コミットメントです。 HSTS は指定した期間ブラウザによって記憶されるため、すべてのサブドメインが HTTPS 上で動作することを確認する間は短い期間から始めて、自信ができたら期間を長くします。

X-Frame-Options は、別のサイトがフレーム内にページをロードできるかどうかを制御します。 <iframe> 他の人のページで。

なぜ気にするのでしょうか？フレーミングはクリックジャッキングの背後にあるメカニズムであり、攻撃者が実際のページを非表示または偽装した要素でオーバーレイして、ユーザーが意図しないものをクリックするようにするためです。アプリにログイン操作 (削除ボタン、支払い、設定変更など) がある場合、それを別の場所にフレーム化することは望ましくないリスクです。

共通の設定は、 SAMEORIGIN, これにより、自分のページが互いにフレーム化されますが、他のページはブロックされます。フレームに入れられるつもりがない場合は、通常、それが正しいデフォルトです。

Referrer-Policy は、ユーザーがページから離れたリンクをクリックしたときに、URL のどの程度を他のサイトと共有するかを決定します。最近のブラウザは通常、strict-origin-when-cross-origin を使用します。同一オリジンのリクエストでは完全な URL を送信できますが、クロスオリジンの HTTPS リクエストはオリジンのみを受け取ります。明示的に弱いポリシーを使用すると、より多くの情報を開示できるようになります。

完全な URL には、トークン、ID、電子メール アドレス、検索語などの機密性の高い値がクエリ文字列に含まれる場合があるため、これは重要です。第三者への漏洩は静かで見逃しやすいものです。

賢明なベースラインは、クロスサイトリクエストではオリジンのみを送信するか、まったく送信しないことです。費用はほとんどかからず、偶発的なデータ漏洩を防ぐことができます。

さらにいくつかのヘッダーが頻繁に表示され、名前を知ることができます。

• X-Content-Type-Options: nosniff ブラウザがファイルの種類を推測するのを防ぎます。そうしないと、アップロードされたファイルが実行可能なスクリプトに変わってしまう可能性があります。

• Permissions-Policy カメラ、マイク、位置情報など、使用しないブラウザの機能をオフにします。

• Cross-Origin-Opener-Policy および関連するクロスオリジン ヘッダーは、ページを他のページから分離し、特定の攻撃を阻止するのに役立ちます。

初日からそれらすべてが必要なわけではありません。機能を理解しておけば、パニックにならずにスキャン レポートを読むことができます。

見る方法は 2 つあります。

まず、手動ルート: 開発者ツールの [ネットワーク] タブで、ページ要求をクリックし、応答ヘッダーを読み取ります。これは、単一のヘッダーが存在することを確認し、期待どおりに設定するのに役立ちます。

2 つ目は、複数のページの実際的な方法です。スキャンを実行します。スキャナーはブラウザーと同じ方法でサイトを取得し、どのセキュリティ ヘッダーが存在するか、どれが欠落しているか、および各ギャップが何を暴露しているかを報告します。これにより、生のテキストの壁の代わりに優先順位付きのリストが得られ、手動で開くとは考えられなかったページがチェックされます。

VICE の無料の軽量セキュリティ スキャンのような汎用ツールは、他の問題とともにヘッダーの検出結果にフラグを立て、各問題の背後にある証拠を示して、問題が発生した理由を確認できます。

ヘッダーは構成内に存在するため、ほとんどの修正は小規模です。サーバー構成に行を追加するか、フレームワークに設定を追加するか、ホストのダッシュボードにオプションを追加します。一度に 1 つのヘッダーを変更し、サイトが引き続き動作することを確認します。

その後、再スキャンします。これは人々がスキップするステップです。構成を編集しても、すべてのページのヘッダーが正しくなったとは限りません。また、ダッシュボードで何かを修正済みとしてマークすることは、それを確認することと同じではありません。同じスコープでの新たなスキャンのみが、変更が実際に有効になったことを示します。

無料のスキャンから始めて、ヘッダーが実際に何をしているのかを確認し、上位の結果を一度に 1 つずつ修正します。これは妥当な最初のパスであり、デフォルトで問題がないと期待するよりもはるかに良い位置です。