最近ウィンナーと燻製の自作にはまっています。@kyo_agoです。
この記事は1/28に行われた、第44回HTML5とか勉強会（HTML5とセキュリティ編）で発表した内容を元に書いています。
今回はApplicationCacheのキャッシュポイズニングに関してお話したいと思います。
最初に用語について説明します。
ApplicationCache
ApplicationCacheとは、HTML5の「Offline Web Applications（日本語訳）」内で定義されているクライアントサイドキャッシュの仕様です。
キャッシュポイズニング
キャッシュポイズニングとは、キャッシュに対して攻撃コードを送り込み、そのキャッシュ経由で攻撃コードを実行させる攻撃手法です。
Googleで「キャッシュポイズニングを検索」した場合、検索結果の上位はDNSのキャッシュポイズニングに関する内容がほとんどですが、最近はクライアントサイドのキャッシュポイズニングも話題に上がるようになっています。
「クライアントサイドのキャッシュポイズニング」自体はApplicationCacheに限らず発生し得る問題ですが、ここでは特にApplicationCacheを使った場合のキャッシュポイズニングの問題に関して紹介したいと思います。
Man in the Middle Attack (MitM：中間者攻撃)
Man in the Middle Attack (MitM)とは攻撃者がターゲット（被害者）とサーバ（コンテンツ提供者）との通信を中継することで、不正な内容に置き換えたり、秘密の情報を盗み見る攻撃です。
具体的な攻撃方法は様々ですが、DHCPサーバの妨害、ルータの乗っ取り、無線APの詐称などで行われることがあります。
どういった問題か
まず、この問題の概要に関して紹介します。
簡単に言うと「安全でないネットワーク上でApplicationCacheを使用した場合に、攻撃データをApplicationCacheに追加させられると安全なネットワークに移動後も攻撃を受け続ける」という内容です。
これに関しては、OWASPという団体が公開している「HTML5 Security Cheat Sheet」や、JPCERT/CCが公開している「HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書」でも、それぞれ以下のように指摘されています。
・HTML5 Security Cheat Sheet – OWASP
Offline Applications
Whether the user agent requests permission to the user to store data for offline browsing and when this cache is deleted varies from one browser to the next. Cache poisoning is an issue if a user connects through insecure networks, so for privacy reasons it is encouraged to require user input before sending any manifest file.
・HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
4.2.3. Offline Web Application
オフラインキャッシュを利用すると、長期にわたりユーザのデバイス上に保存されたリソースが使用されることになる。そのため、例えば暗号化されていないWi-Fiのような信頼できないネットワークを利用している端末に対して、攻撃者が中間者攻撃により汚染したリソースをオフラインキャッシュとして保存させた場合、そのネットワークを離れた後も長く汚染されたリソースをユーザが使い続けることになり、結果として、例えば秘密情報が攻撃者のサイトに送信されるなどの被害の可能性も考えられる。そのため、Offline Web Applicationの機能を利用する場合は、当該リソースを持つサイト全体に対してhttpsを利用することが望ましい。
攻撃シナリオ
概要のみだとどういった攻撃手法か理解しづらいため、具体的にどういった攻撃シナリオになるかを紹介します。
- ターゲットの通信を乗っ取る（MitMを仕掛ける）
- ターゲットがhttpでhtmlを要求したら、取得したhtml内に汚染したいURLをiframe[src]で記述して返す
- iframe[src]で指定したURLをブラウザが取得しようとした場合、正規のhtml内に汚染したJSとApplicationCache自体のURLを記述したApplicationCacheを指定する
この攻撃のポイントとしては以下の2点です。
- 中間者攻撃（MitM）が前提である
ターゲットが取得しようとしたhtmlを書き換える必要が有るため、中間者攻撃（MitM）が前提となります。 - ApplicationCache自体のURLをApplicationCacheに記述する
ApplicationCacheは以下のようにApplicationCacheファイル（.appcache）にApplicationCacheファイル自体のURLを記述すると自動的にキャッシュが消えなくなります。
アプリケーションキャッシュの使用 – HTML | MDN
CACHE MANIFEST
/manifest.appcache
再度攻撃シナリオを見返す
ここで再度上で紹介した「攻撃シナリオ」を見てみたいと思いますが、まず最初にターゲットの通信を乗っ取っています。
つまり、この攻撃は「ターゲットの通信を乗っ取る（中間者攻撃（MitM）を行う）」事が前提になっており、この点でCSRFやXSSなどの攻撃手法とは性質が異なります。
（MitMができない場合、この攻撃は成立しない）
また、この攻撃はApplicationCacheを使うことでファイルが消えにくくなりますが、ApplicationCacheを使用しなかったとしても攻撃者がhttp headerを改変してキャッシュを有効にすることで攻撃コードを埋め込んだまま攻撃を継続することができます。
キャッシュポイズニングにおける本質的な課題
この記事ではここまで「各種セキュリティ団体が紹介するApplicationCacheのキャッシュポイズニングに関する注意喚起」の内容を紹介してきました。
しかし、著者はこの問題に関して「中間者攻撃（MitM）が必須である」という点で、他の攻撃手法とは性質が異なると考えます。
そもそもWebの世界では「コンテンツ提供者が中間者攻撃（MitM）に対処するにはhttpsしかない」という前提があります。
（MitMが成立した場合、攻撃者はコンテンツ提供者以上の権限を持つためコンテンツ提供者の対処を全て無効化できる）
そのため、「中間者攻撃（MitM）が必須である」場合、コンテンツ提供者がコーディングレベルで対応できることはありません。
また、「ApplicationCacheを使用しなくても同じような攻撃は可能である」点から、ApplicationCache自体の問題とすることにも疑問を感じます。
この問題は簡単に言うと「中間者攻撃（MitM）でキャッシュを汚染させられる」問題であり、ブラウザに外部の実行コード（html、JS等）をキャッシュする機構が備わっている以上避けられない問題だと考えます。
コンテンツ提供者がとるべき対応策は？
それではコンテンツ提供者はこの問題に対してどう対処すべきでしょうか。
基本的にコンテンツ提供者はコーディングレベルでこの攻撃方法に対処する方法はないと考えます。
何らかの対処コードを作成できたとしても、中間者攻撃（MitM）が成立している時点で、攻撃者は対処コードを除外した形でキャッシュを汚染することが可能です。
そもそもこの問題はApplicationCacheの問題ではなく、中間者攻撃（MitM）の問題のためサイト全体をhttpsにする以外、根本的な対応方法はありません。
結論
現時点での著者の結論をまとめます。
「ApplicationCacheのキャッシュポイズニング」に関して言うと、「コンテンツ提供者がApplicationCacheを使っている」ことで新しい脅威が増えるということはありません。
（攻撃者はコンテンツ提供者がApplicationCacheを使っているかどうかに関わらず、ApplicationCacheの機能を有効化して汚染できる）
中間者攻撃（MitM）に対しての対応は、これまでどおりサイトをhttps化することが有効になります。
利用者としては汚染が懸念されるネットワークの利用はできるだけ避けて、もし使用せざるを得ない場合ブラウザをシークレットモードで使用し、「サイトがhttpsで通信しているか」も確認した上で使用しましょう。