現状の違反（GZIP SSL Attack）？
BREACHが私たちの心に浸透してから1年が経過し、それ以来、記事や投稿、パッチがなくなったようですが、私のGoogle-fuは弱まっていますか？
- BREACHは、Apache/nginxで緩和またはパッチされていますか？
- さらに保護を提供する場合、SSLでGZIPを有効にできますか？
違反は、いくつかの条件が満たされた場合に存在する脆弱性です。
- HTTP圧縮が使用され、
- 入力の一部が反映され、
- 静的シークレットは応答のHTTPボディに存在し、
- 攻撃者は暗号化された応答のサイズを読み取ることができ、
- 攻撃者は攻撃を受けているサイトへのリクエストを偽造することができます。
これらの各条件はそれ自体で脅威をもたらすことはありませんが、組み合わされて脆弱性につながります。これが、この脆弱性に対する明確な解決策がない理由の1つです。ApacheまたはOpenSSLをアップグレードするだけでは十分ではありません。すべてに対してgzip圧縮を無効にすることはあまり意味がありません。ほとんどの場合、ユーザー入力を反映することはまったく問題ありません。本当に簡単な解決策はありませんが、ここ数年、BREACHを軽減するためにいくつかの進歩がありました。
最良の解決策の1つは same-site cookie flag です。これにより、Cookieがクロスオリジンリクエストで機能しなくなり、CSRF攻撃が解決されるため、BREACHも解決されます。誰かが 仕様 に取り組んでおり、すでに Chrome 、 Firefox 、および Windows 10のEdge に実装されています。 Chromeは、すべてのCookieの作成にも取り組んでいます デフォルトではSameSite 、つまり、ChromeでのBREACHおよびその他すべてのCSRFのような攻撃を解決します。
応答の長さをランダム化するプロジェクトもいくつかあります。 Somemodules 各応答にランダムなHTMLコメントを入れます。これは完全なハックです。パディングのサポートは TLS 1. で形式化されていますが、サーバーに実装されるまでにはしばらく時間がかかります。
一部のフレームワークは、特にCSRFトークンの推測を防ぐために、BREACH攻撃を軽減するための措置も講じています。 Django リクエストごとにCSRFトークンをランダム化するため、複数のリクエストで推測することはできません。これは比較的新しいもので、Django 1.10で今年リリースされました。
攻撃者の進歩もありました。今年の研究者たちは、BREACHは タイミング攻撃（HEIST） にも変換できることを示しています。ブラウザでJavascriptを実行するだけで悪用される可能性があります。最後に、 new toolkit（Rupture） も、圧縮サイドチャネルの脆弱性を悪用するために今年開発されました。