web-dev-qa-db-ja.com

HTTP圧縮は安全ですか？

CRIME攻撃により、圧縮を使用すると機密性が危険にさらされる可能性があることがわかりました。特に、攻撃者が提供したデータを機密の秘密データと連結し、連結を圧縮および暗号化することは危険です。システムスタックの任意の層で発生していることがわかったときはいつでも、CRIMEのような攻撃の可能性を疑う必要があります。

現在、CRIME攻撃は、少なくともこれまで公に説明されているように、TLS圧縮に対する攻撃です。背景：TLSには、TLSレベルで発生する組み込みの圧縮メカニズムが含まれています（接続全体が圧縮されます）。したがって、攻撃者が提供したデータ（たとえば、POSTリクエスト）の本文）がシークレット（たとえば、HTTPヘッダーのCookie）と混ざり合う状況があり、これがCRIMEを有効にしました攻撃。

ただし、圧縮を使用するシステムスタックの他の層もあります。特に HTTP圧縮 について考えています。 HTTPプロトコルには、HTTP経由でダウンロードしたリソースを圧縮するための組み込みサポートがあります。 HTTP圧縮が有効になっている場合、圧縮は応答の本文に適用されます（ヘッダーは適用されません）。 HTTP圧縮は、ブラウザーとサーバーの両方がサポートしている場合にのみ有効になりますが、 パフォーマンスが向上する であるため、ほとんどのブラウザーと 多くのサーバー がサポートします。 HTTP圧縮はTLS圧縮とは異なるメカニズムであることに注意してください。 HTTP圧縮はスタックの上位レベルでネゴシエートされ、応答の本文にのみ適用されます。ただし、HTTP圧縮は、SSL/TLS接続を介してダウンロードされるデータ、つまりHTTPSを介してダウンロードされるリソースに適用できます。

私の質問：HTTPSリソースでHTTP圧縮を使用しても安全ですか？ HTTPS経由でアクセスされるリソースのHTTP圧縮を無効にするために特別なことをする必要がありますか？または、HTTP圧縮がなんらかの理由で安全なのに、なぜ安全なのでしょうか。

cryptographytls
43
D.W.

それは私には危険なようです。静的リソースの場合はHTTP圧縮で問題ありませんが、SSLを介して提供される一部の動的リソースの場合、HTTP圧縮は危険なようです。 HTTP圧縮は、状況によってはCRIMEのような攻撃を許すように思えます。

次の特性を持つ動的ページを持つWebアプリケーションを考えてみます。

  1. HTTPS経由で提供されます。

  2. サーバーはHTTP圧縮をサポートしています（ブラウザーがHTTP圧縮をサポートしている場合、このページは圧縮形式でブラウザーに送信されます）。

  3. ページのどこかにCSRFトークンがあります。 CSRFトークンは、セッションの存続期間中（たとえば）固定されています。これは、攻撃が学習しようとする秘密です。

  4. このページには、ユーザーが指定できる動的コンテンツが含まれています。簡単にするために、ページに直接エコーされるURLパラメータがあると仮定します（おそらく、XSSを防ぐためにHTMLエスケープが適用されていますが、これは問題なく、上記の攻撃を阻止しません）。

次に、CRIMEスタイルの攻撃により、攻撃者がCSRFトークンを学習し、WebサイトにCSRF攻撃を仕掛けることができると思います。

例を挙げましょう。ターゲットのWebアプリケーションがwww.bank.comの銀行のWebサイトであり、脆弱なページがhttps://www.bank.com/buggypage.htmlであるとします。銀行がSSL（https）でのみ銀行業務にアクセスできることを保証するとします。また、ブラウザがhttps://www.bank.com/buggypage.html?name=D.W.にアクセスすると、サーバーは次のような漠然としたHTMLドキュメントで応答するとします。

<html>...<body>
Hi, D.W.!  Pleasure to see you again.  Some actions you can take:
<a href="/closeacct&csrftoken=29238091">close my account</a>,
<a href="/viewbalance&csrftoken=...">view my balance</a>, ...
</body></html>

攻撃者がすべてのネットワークトラフィックを盗聴できるように、開いているWifi接続を介してWebを閲覧しているとします。現在銀行にログインしているため、ブラウザーは銀行のWebサイトとのセッションを開いていますが、実際には開いているWifi接続を介して銀行取引を行っていないとします。さらに、攻撃者があなたを攻撃者のWebサイトhttp://www.evil.com/に訪問するように誘導することができると仮定します（たとえば、おそらく中間者攻撃を実行し、他のhttpサイトにアクセスしようとしたときにリダイレクトします）。

次に、ブラウザーがhttp://www.evil.com/にアクセスすると、そのページが銀行のWebサイトへのクロスドメインリクエストをトリガーし、秘密のCSRFトークンを取得しようとします。 JavaScriptがクロスドメインリクエストを行うことが許可されていることに注意してください。 same-Originポリシーでは、クロスドメインリクエストへの応答を確認できません。それにもかかわらず、攻撃者はネットワークトラフィックを盗聴できるため、暗号化されたすべてのパケットの長さを監視し、SSL接続を介して銀行にダウンロードされるリソースの長さについて推測することができます。

特に、悪意のあるhttp://www.evil.com/ページがhttps://www.bank.com/buggypage.html?name=closeacct&csrftoken=1へのリクエストをトリガーし、結果のHTMLページがどの程度圧縮されているかを確認できます（パケットを盗聴し、銀行からのSSLパケットの長さを調べます）。 。次に、https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2へのリクエストをトリガーし、応答がどの程度圧縮されているかを確認できます。など、CSRFトークンの最初の桁の可能性ごとに。それらのうちの1つは他のものより少し良く圧縮するはずです：URLパラメータの数字がページのCSRFトークンと一致するもの。これにより、攻撃者はCSRFトークンの最初の数字を知ることができます。

このように、攻撃者はCSRFトークン全体を学習するまで、CSRFトークンの各桁を学習し、桁ごとに回復できるように見えます。その後、攻撃者がCSRFトークンを知ったら、www.evil.comの悪意のあるページに、適切なCSRFトークンを含むクロスドメインリクエストをトリガーさせ、銀行のCSRF保護を無事に破ることができます。

これにより、HTTP圧縮が有効になっている場合、上記の条件が当てはまる場合、攻撃者がWebアプリケーションにCSRF攻撃を成功させる可能性があります。シークレットを攻撃者が制御するデータと同じペイロードに混合し、そのペイロードを圧縮および暗号化しているため、攻撃が可能です。

動的HTMLに格納されている他の秘密がある場合、それらの秘密を知るために同様の攻撃が可能になる可能性があると想像できます。これは私が考えている種類の攻撃のほんの一例です。したがって、HTTPSを介してアクセスされる動的ページでHTTP圧縮を使用することは少し危険であるように私には思えます。静的なページ/リソース（CSS、JavaScriptなど）を除いて、HTTPS経由で提供されるすべてのリソースでHTTP圧縮を無効にするのに十分な理由がある場合があります。

50
D.W.

一般に、圧縮は圧縮される長さを変更します（それがまさに圧縮の理由です）。 可逆圧縮 は、データ自体に応じて長さを変更します（非可逆圧縮は、MP3ファイルなどの固定圧縮率に達する可能性があります）厳密な128 kbit/sで）。データ長は、暗号化を通じて漏洩するものです。そのため、私たちはそれに興味を持っています。

非常に一般的な方法では、パッシブのみの攻撃者が存在する場合でも、長さのリークは致命的な可能性があります。 トラフィック分析 のようなものです。例は第一次世界大戦からであり、フランスの暗号学者は（暗号化された）ヘッダーの長さに基づいてメッセージの重要性を予測できました：重要なメッセージが大佐（Oberst）中尉（Oberleutnant、はるかに長い用語）のタグが付けられている重要性の低いメッセージに対して。

メッセージの長さを正規化することによって長さのリークを修正できないため、圧縮によって長さのリークはさらに悪化します。

攻撃者が圧縮されたチャンクに独自のデータを追加できる場合、攻撃者は増幅の長さのリークを引き起こし、これはCRIME攻撃が示すように、任意のターゲットデータ。しかし、問題はすでにそこにあったと私は主張します。その見方では、HTTPレベルの圧縮は新しいリスクではありません。それはむしろ、既存のリスクを悪化させる要因です。攻撃者に暗号化されたストリームに自分のデータの一部を追加させることは、さらに別の悪化要因であり、これらの要因はさらに増加し​​ます。

あなたがこの考えを持っている最初の人ではないことを私は賭けます。多くの人（私を含む）が過去10日間にいくつかのことを考えただけでなく、このURLにアクセスしようとすると、次のようになります。

http://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

次に、Googleから「sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa」という単語を含む404エラーが表示されます。ねえ、それは攻撃者が反射データを選んだので、それは楽しいかもしれません！では、HTTPS URLでもう一度試してみましょう。

https://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

そして、404も楽しくもない、あなたは無意識のうちにGoogleのホームページにリダイレクトされます。これにより、Googleの一部の人々もすでにそれを考えており、SSLを使用する場合は事前にリフレクションビットを無効にしたと思います（SSLを使用すると、Google +のベルとホイッスルが表示されるため、潜在的に危険なデータになります）。

26
Thomas Pornin