web-dev-qa-db-ja.com

静的なWebサイトに適したセキュリティ対策はどれですか。

静的なWebサイトがあります。ユーザーはログインしたり、その他のアクションを実行したりできません。私のサイトにとって一般的なHTTPセキュリティ対策はどれですか。

これらのいずれかが必要ですか?

151
Sjoerd

一般的なWebアプリケーションの攻撃方法は、厳密に静的なWebサイトには当てはまりません。インタラクティブな要素がなければ、ハイジャックするアカウントや盗むCookieはありません。それでも、デリケートなコンテンツをホストしていない場合でも、暗号化されたアクセスを訪問者に提供する必要があります。

TL; DR

HSTSでHTTPSを使用して、訪問者に対してある程度のプライバシーとコンテンツの整合性を確保します。 HPKPを静的サイトに追加することは、不必要に偏執狂的である可能性があり、展開する際には注意が必要です。議論されている他のセキュリティ対策は、ほとんど静的サイトには関係ありませんが、実装が非常に簡単なので、引き続き使用することを決定するかもしれません。


HTTPS

はい、それを行います。Let's Encrypt のような無料のSSL証明書プロバイダーでは、切り替えない非常に正当な理由が必要です。 HTTPSは、静的コンテンツであっても望ましい送信データのプライバシーと整合性を保護します。

整合性違反のシナリオ:ダウンロードを提供する場合、中間者攻撃者がファイルを改ざんしてマルウェアを配布する可能性があります。プライバシー違反の例:私の雇用主、所有者が接続しているWiFiホットスポット、またはISPはすべて、私が読んでいる正確な記事やサイトからダウンロードしているコンテンツをすべて見ることができます。ただし、HTTPSを使用すると、ほとんどの場合、メタデータ(接続しているIPアドレス、 SNIによるホスト名など )を公開します。

HTTP Strict Transport Security

はい、実行します。HSTSは、ユーザーに only HTTPSを使用してWebサイトに接続することを強制するのに役立ちます。 SSLストリッピング 攻撃の防止。 HTTPSを展開する場合、HSTSをフォローアップすることは非常に理にかなっています。次のように、追加の応答ヘッダーを追加することで簡単に実装できます。

Strict-Transport-Security: max-age=31536000

HSTSはユーザーが最初にヘッダー( TOFUモデル )に遭遇してからmax-ageタイムアウトに達するまで有効になるため、サイトを HSTSに送信することもできますプリロードリスト 。これにより、ユーザーは最初のアクセスからHTTPS経由で接続を開始します。

HSTSを有効にした後、 プレーンHTTPに戻すのは面倒です

HTTP公開鍵のピン留め(「証明書のピン留め」)

状況によって異なります。HSTSはブラウザに特定の時間に厳密にHTTPSを使用するように指示しますが、HPKPヘッダーは、ブラウザが将来信頼する証明書を指定します。証明書チェーンから公開鍵を固定すると、攻撃者が証明書を不正な証明書に置き換えるのを防ぎます。攻撃者はCAを危険にさらして不正な証明書を発行できるようにする必要があるため、このような攻撃はほとんどありません(ただし、 の前に発生します)。さらに、HPKPをセットアップするときは注意が必要です。デプロイメントの欠陥により サイトが利用できなくなる 以前のユーザーがアクセスできなくなる可能性があるためです。

Detectify LabsのHPKPに関する 優れた記事 には、より楽観的な結論があります。

HPKPを使用する必要がありますか?はい、そうすべきです。正しくピン留めすると、すべてが南向きになる可能性はかなり低くなります。

コンテンツセキュリティポリシー

はい、しかし実際には必要ないかもしれません。CSPは、Originが許可されるリソースタイプを制限することにより、XSSおよび関連する攻撃を軽減するために作成されましたあなたのサイトによって読み込まれます。純粋に静的なWebサイトがあり、おそらく外部ソースをまったく埋め込まないため、実際の攻撃ベクトルではない可能性があります。賢明なポリシーは、ロードするリソースの種類によって異なります。たとえば、この制限付きポリシーヘッダーでは、同じオリジンからのコンテンツのみが許可されます。

Content-Security-Policy: default-src 'self'

クリックジャッキング保護

はい、なぜでしょうか。クリックジャック攻撃は、ユーザーをだまして偽装したフレームを介してWebサイトと無意識にやり取りさせます。ただし、インタラクティブな要素がない場合は、実際にダメージを与える必要はありません。 (ただし、より良い世界では、クロスオリジンフレームはオプトイン機能になります。)実装は簡単です。この例では、フレームの埋め込みを一切禁止します。

X-Frame-Options: Deny

XFOヘッダーはframe-ancestors CSPディレクティブを支持して廃止と宣言されていることに注意してください。

Content-Security-Policy: frame-ancestors 'none' 

コンテンツ盗聴防止

はい、理由はありません。コンテンツタイプを正しく宣言しないと、ブラウザがタイプを推測(sniff)する場合があります(その動作は一般的ではなくなりました)。 。これは、実行可能でないはずのコンテンツタイプが見つからないためにスニッフィング後に実行可能形式であると判断されるユーザーコンテンツでは特に危険です。ほとんど問題にならないあなたの静的なサイトで。安全のために、次のヘッダーを追加してスニッフィングを防ぐことができます(ただし、適切に宣言されたMIMEタイプの代わりにはなりません)。

X-Content-Type-Options: nosniff

参照: X-Content-Type-Optionsは、コンテンツスニッフィング攻撃を本当に防ぎますか?


OWASPセキュアヘッダープロジェクト を見て、セキュリティ関連のヘッダーと実際の例の詳細を確認してください。

130
Arminius
  • HTTPS
  • 厳格な輸送セキュリティ
  • 証明書のピン留め

これらは、盗聴や改ざんからデータの転送を保護します。この保護は、ブラウザからの要求だけでなく、応答にも適用されるため、静的なサイトに対しても完全に有効です。

  • コンテンツセキュリティポリシー

他の側のコンテンツを含めない場合、おそらく必要ではありませんが、害もありません。広告、画像、フォント、スクリプトなど、コントロールの外部に外部コンテンツを含める場合は、制限するのが理にかなっています。

  • クリックジャッキング保護

信頼できる参照元(つまり、サイト)に基づいて機能する他のサイドへのリンクを含める場合、またはソーシャルメディアボタンなどを含める場合、フレーミングを制限することは理にかなっています。そうでない場合は、サイトを他のユーザーがフレーム可能にすることを明示的に望まない限り、害はありません。

  • コンテンツ盗聴防止

コンテンツスニッフィングがアクティブなときに解釈が異なる可能性があるコンテンツを提供する場合(たとえば、HTMLをtext/plainとして提供してソースコードを表示する)、コンテンツスニッフィング保護を有効にすることは理にかなっています。そうでない場合、害はありません。

30
Steffen Ullrich

あなたがウェブサイトを計画している間、特にそれがあなたのビジネスウェブサイトであるとき、あなたは常にそれに特別な注意を払う必要があることを考慮すべき非常に多くの事柄があります。ただし、静的なWebサイトは他のサイトよりもリスクの数が少ない傾向がありますが、それでも上記のように重要なセキュリティの側面に従っている必要があります。ここで示す詳細は、さまざまな種類のサイトのセキュリティの懸念に関する追加の知識を共有することだけです。 @Arminiusと@Steffenがほとんどの疑問を解消したので、ここに多くを追加する必要はありません。それでも私のビューを追加しましょう:

HTTPS:

多くのウェブサイトは、静的サイトがSSL証明書を必要としないと信じていましたが、現在、SSLをサイトの重要な側面として検討しています。最初の理由は Googleの発表 ランキングの向上についてです。別の理由は、ブラウザによる非HTTPSサイトの扱いです。

HSTS:

HTTP Strict Transport SecurityまたはHSTSは、Webサイトを cookies hijacking から保護するセキュリティプロトコルであり、ダウングレード攻撃は、WebサーバーがWebブラウザーやその他のエージェントで安全なHTTPS接続のみを許可することを示します。このポリシーは、HTTPSセキュリティに追加のレイヤーを追加し、Webサイトとそのユーザーのセキュリティを維持するのに役立ちます。

CSP:

XSS( クロスサイトスクリプティング )、コードインジェクションのような攻撃は、ウェブサイトのパフォーマンスを損なうだけでなく、耐え難いコンテンツを置くことによって評判を殺します。静的なサイトでも動的なサイトでも、悪意のあるコードの挿入により、Webサイトが問題を起こす可能性があります。マルウェア対策ソフトウェアと定期的な脆弱性評価を使用すると、Webサイトがこのような望ましくない攻撃を防ぐのに役立ちます。

HPKP:

HTTP公開キーのピン留め(HPKP)は、悪意のある意図で不正な証明書を発行するように制限することにより、攻撃者を回避する効果的な方法です。 HPKPは、証明書のピン留めとしてよく知られており、HTTPS Webサイトが攻撃者に抗議して不正な証明書の発行を停止できるようにするセキュリティメカニズムです。

クリックジャッキング:

この手法は、ユーザーを偽のページまたはダウンロードに転送する海賊版映画サイトで非常に人気があります。 Malwartising アクティビティでクリックジャッキング手法をまとめて使用すると、攻撃者が何かを偽装してマルウェアを拡散する場合があります。

コンテンツスニッフィング:

コンテンツスニッフィングは、バイト単位で存在するコンテンツをキャプチャまたは監視するため、攻撃者はコンテンツのファイルタイプを推測できます。コンテンツスニッフィングとは、正しい方法で推定されるファイルをレンダリングするように設定されている不正確なメタデータを指します。

5
Gunjan Tripathi

これは私の意見です:

  • HTTPS
  • 厳格な輸送セキュリティ
  • コンテンツ盗聴防止
  • 証明書のピン留め

カスタム情報や保護された情報を提示しない場合、静的サイトでスニッフィングから保護する必要があるのはなぜですか?静的サイトの情報は公開されていると思いますので、カバーする必要はありません。

  • コンテンツセキュリティポリシー

動的コンテンツも外部コンテンツも含めない場合(静的サイトは含まない)。次に、これはどちらも必要ありません。 XSS攻撃の可能性がないため。

  • クリックジャッキング保護

Steffen Ulrich として、明示的にサイトを他のユーザーによるフレーム可能として設定しない限り、これは必要ありません。

結論として、厳密に静的なWebサイトを設定している場合は、これらのセキュリティ対策は必要ありません。

いずれにせよ、近い将来このサイトを編集してより動的にすることができると思われる場合は、可能な限りすべてのセキュリティ対策を追加してください。

2
KanekiDev