web-dev-qa-db-ja.com

Webサイトは実際にどのようにBREACHを模倣していますか？ （HTTPS +圧縮）

このWebサイトでBREACHに関するよくある質問と回答を読んだ後の唯一のアドバイスは、シークレット（CSRFトークンを含む）を含む可能性のあるものを圧縮しないことです。しかし、それは素晴らしいアドバイスのようには聞こえません。ほとんどのウェブサイトは実際にはすべてを圧縮しているので、BREACHを防ぐために正確に何をしているのかと思います。 StackExchangeでパスワードを変更するためのフォームを使用してページを確認したところ、圧縮されています。 Googleでもすべてが圧縮されているようです。また、セキュリティに関心があると思われる他の多くの重要なウェブサイトもあります。では、彼らは侵害を防ぐために何をしているのでしょうか？

ここに私が集めることができた可能な解決策のリストがあります：

  • 圧縮を完全に無効にします。これは帯域幅を浪費することを意味し、誰もこれを行っていないようです。
  • 静的リソースのみを圧縮 CSSやJSと同様。良い考えです。これが実装するのに最も速いソリューションであり、最適化する必要があるいくつかのWebサイトでこれを実行する予定です。
  • リファラーのチェックそして、許可されていないウェブサイトからのリクエストがあるときはいつでも圧縮を避けます。興味深いアイデアですが、「ダーティトリック」のように聞こえ、完璧とはほど遠いです（一部のクライアントはリファラーを抑制し、他のWebサイトや検索エンジンからのすべてのトラフィックは圧縮されていないページをロードすることになります）。
  • リクエストを制限するレートこれは間違いなくGoogleによって実装されています。あまりに多くのリンクをクリックしすぎると、CAPTCHAが表示される場合があります（SERPでWebサイトの位置を確認しているときに、文字通りボットのように振る舞っていた）。しかし、Webサイトは実際に侵害を軽減するためにこれに依存していますか？そしてそれは信頼できますか？たとえば、設定する賢明で効果的な制限は何ですか？
  • HTTPヘッダーでCRSFトークンを使用ページの本文の代わりに。 StackExchangeでこれに気づいたことはありませんが、Googleにはトークンのように見える興味深いHTTPヘッダーがあるようです。トークンが常にチェックされていれば（情報を変更するためだけでなく、情報を表示するためであっても）、これは本当に問題を軽減すると思います。これは完璧なソリューションだと思いますが、ゼロから実行しない限り、実装するのが最も困難です（アプリケーションのいくつかの部分を書き換える必要があります）。

だから質問は：上記の点は有効ですか？他のオプションはありますか？そして、実際に行っているベストプラクティスに従うWebサイトは何ですか？

tlsthreat-mitigationside-channelcompressionbreach
4
reed

BREACHを効果的に軽減するにはいくつかの方法がありますが、それらにはすべてトレードオフがあります。これらの緩和策がどのように機能するかを理解するには、BREACHがどのように機能するかを確認する必要があります。

TLSセキュリティを侵害するにはどうすればよいですか？

BREACHに関するこのプレゼンテーションのp。1 によると、秘密の成分は次のとおりです。

  • 応答本体の圧縮
  • 安定したページ
  • 応答本文の秘密
  • 攻撃者が提供するデータ
  • 既知の接頭辞

最も目立つのは、攻撃者が提供したデータとの両方がクライアントシークレットと同じ応答である必要があることです。さらに、攻撃者はクライアントが多くの応答を受信できるようにする必要があり、それらすべてに攻撃者からの変更された入力を含める必要があります。

したがって、たとえば、BREACHを使用してセッションCookieを抽出したい場合、ペイロード（例：4bf8dfc73...）をこのアンサー本文に書き込み、継続的に更新することはできません。実際には、更新ごとに応答を受け取る必要があります。

ご覧のとおり、これは非常に複雑な設定です。確かに、一部の<iframe>- magicを使用してこれらすべてを実行することは可能ですが、一部のサイトが<iframe>経由でのロードを拒否するか、ブラウザに指示するまで、それらはおおむね好意的ではなくなりましたドキュメント内の<iframe>を開かないでください。

それをすべて知った上で、サイトは侵害を軽減するために何をしますか？

彼らはそれを無視します

これは、最も一般的なアプローチの1つです。最初は安全ではないように思えるかもしれませんが、BREACHを実行可能にするために調整する必要のある事項がいくつもあるとすれば、それを気にしないだけでもかなり実行可能な戦略のようです。

それが確かに実行可能な場合：-クライアントシークレットが応答にない-サイトが純粋に静的である

静的リソースを圧縮するだけ

これは別の非常に一般的な代替手段です。スタイルシートやスクリプトなどの静的な圧縮可能なリソースはすべて圧縮されますが、動的なリソースはすべてそのまま配信されます。

ただし、このようなリソースの多くは既に縮小されていることに注意してください。つまり、それ以上圧縮しても、より良い結果は得られません。

ただし、このアプローチでは、少なくともsomeの圧縮が行われますが、BREACHに対して脆弱ではないことを確認できます。

圧縮を完全に無効にする

別の実行可能な戦略。上で述べたように、多くの静的リソースはとにかくいくらか圧縮されているため、さらに圧縮すると、とにかく収益が減少します。特にネットワークリソースに問題がない場合は特に、圧縮を無効にするだけでも問題ありません。

シークレットを個別に読み込む

もう1つの緩和策は、クライアントシークレットを個別にロードすることです。この場合、攻撃者が制御するデータを挿入できません。このように、すべてのリクエストに対して圧縮を有効にすることができ、攻撃者が制御するデータは常にクライアントシークレットから分離されます。

人々がBREACHを緩和しようとした他の方法があると確信しています。しかし、これらは私が見た方法であり、私は個人的に同意します（そうです、気にさえしません）。

4
MechMK1

あらゆる専門家からのアドバイスと同様に、あなただけが行うことができるリスク評価があります。

  • 圧縮なしで実行できますか？はい。
  • 違反が発生した場合はどうなりますか？ （あなたの答え：あなたは刑務所に行きます-罰金を科せられますか???）

標準と推奨事項は明確です：TLS 1.2以前の場合 トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項

「圧縮関連の攻撃（ [RFC7457]のセクション2.6）に要約されています を防ぐために、実装と展開は、TLSレベルの圧縮を無効にする必要があります（ [RFC5246]のセクション6.2.2 ）、問題のアプリケーションプロトコルがそのような攻撃に対して開かれていないことが示されている場合を除きます。」

そして述べたように トランスポート層セキュリティ（TLS）プロトコルバージョン1.3セクション1.2 「圧縮の削除」

OWASP トランスポート層保護のチートシート 「攻撃者がセッションCookieなどの機密情報を回復できる可能性がある脆弱性（ニックネームはCRIME）から保護するために、TLS圧縮を無効にする必要があります。」

0
jwilleke