App Engine セキュリティー情報 - BREACH attack について

[Takashi Matsuo]

App Engine に関するセキュリティ情報です。

最近報告された BREACH[1] と呼ばれる攻撃手法は、もし攻撃者が暗号化された HTTPS パケットをキャプチャすることができるならば、被害者のブラウザーからたった数千のリクエストを送ることで、HTTPS レスポンスボディ内のコンテンツを複合できるものです。広範囲に影響があるシリアスな問題です。

攻撃が成功するためにはいくつか条件があって、

• HTTPS を使っていて、HTTP レベルで圧縮している（gzip, deflate）
• コンテンツの長さがいつも全く同じか、殆ど同じ
• 対象になる秘密は数千のリクエストで同じか、殆ど同じ値

BREACH は CRIME[2] と呼ばれる攻撃手法の亜種であり、Google のセキュリティーチームではだいぶ前に HTTP header を対象にした CRIME Attack に対しての対策を終了しており、HTTP header に対する CRIME Attack のリスクは最小限に留めることができています。

残念ながら、App Engine のアプリケーションは、BREACH の対象になりえます。さらに App Engine では、web ブラウザーが特定のヘッダーを送った場合、レスポンスは自動的に gzip 圧縮されますので、現在のところ事実上 HTTP 圧縮を止めるオプションを選択できません。ただし、この攻撃へのリスクを減らすための対策がいくつかあるのでご紹介します。

• 全てのリクエストにおいて、新しく XSRF トークンを作る。同じトークンを使いまわすと、BREACH Attack の対象になります。毎回別のトークンを使うように設定しましょう。
• 機密情報（セッションID、 クレジットカード番号、個人情報など）を配信するエンドポイントと、ユーザーが任意に入力できる値を含むレスポンスを配信するエンドポイントを分ける。
• どうしても機密情報とユーザー入力を混ぜて配信しなければならないのであれば、ランダムな要素を導入する。例を２つ挙げます。
• AJAX レスポンス全体を暗号化して配信し、クライアント側で複合する。
• HTML ページを配信している場合は全体を暗号化できないので、ランダムな文字列を作成し、機密情報又はユーザー入力に対して XOR した結果と、このランダム文字列を結合したものを配信し、元のデータを表示・使用する場合はランダム文字列で再度 XOR してから使用する。

また、これは App Engine 上での開発とは直接関係ないのですが、この攻撃が成立するのは、システムが複数のソースからのデータ（例: XSRF トークンとユーザー入力）をまとめて圧縮してしまっているからです。もし、あなたがデータを圧縮し暗号化するようなシステムをデザインしているのであれば、この攻撃手法からの教訓を活かして、データを混ぜて圧縮するのは避けてください。

Google のセキュリティーチームでは、この新たな BREACH Attack に対しても対策を講じる予定です。続報があればこちらでお知らせします。

1. http://breachattack.com/

2. http://en.wikipedia.org/wiki/CRIME_(security_exploit)

--

Takashi Matsuo | Developers Programs Engineer | tma...@google.com