XCS: Cross Channel Scripting and its Impact on Web Applications

Hristo Bojinov, Elie Bursztein, and Dan Boneh, XCS: Cross Channel Scripting and its Impact on Web Applications, ACM CCS 2009.

WebとWeb以外のチャネルにまたがってスクリプトインジェクト攻撃を行うものを XCS と呼び、攻撃手法の分類と、この攻撃への対策となる Site Firewall の提案。

XCSは大まかにいって、以下の3種類に分類される。

• Web以外のチャネルからJavaScriptをインジェクトし、Webブラウザで見たときに実行させる XCS
  • たとえば、Webの管理インタフェースを持つNASなどで、ファイルを格納するときに、ファイル名にスクリプトをインジェクトしておく。すると、Webの管理インタフェースから見たときに、スクリプトが解釈されて実行される。
  • P2Pを介したXCS。BitTorrentから直接ファイルをダウンロードする機能を持っているようなNASの場合、ファイル名にスクリプトを仕込んだファイルをアップロードしておく
  • Logを介したXCS。たとえば存在しないユーザ名で管理コンソールにログインしようとすると、ログインが失敗して、ユーザ名がログに記録される。このとき、あらかじめユーザ名にスクリプトを仕込んでおくと、管理者がWebの管理コンソールでログを見たときに、スクリプトが実行される。
  • 携帯電話のXCS。Google Android や Palm WebOSはアプリケーションビューを作るのにHTMLとJavaScriptを使っているので、なんらかの方法でスクリプトをインジェクトできる可能性がある。現に、Palm PreではXCS脆弱性が報告されているらしい。
• 逆に、Webのチャネルから攻撃をインジェクトし、Web以外のチャネルを攻撃するのが reverse XCS
  • もともとWeb管理コンソールつきのフォトフレームで、XSSやCSRF脆弱性のあるものに対して、ユーザのブラウザ経由で攻撃コードをインジェクトするようなものを reverse XCSと呼んでいるらしい。
• RESTful APIを利用する RXCS. FacebookやTwitterなどREST APIを提供するSNSがあるが、これらのAPIを利用するサードパーティアプリを攻撃する。
  • たとえばFacebookの場合、ユーザの入力データを表示する際にエスケープするので、サードパーティアプリでちゃんとエスケープしていないと攻撃が発生する
  • Twitterの場合はユーザ入力に対してエスケープした上で格納しているので、サードパーティアプリは常にエスケープしたデータを取得することになる。が、サードパーティアプリの中でアンエスケープしたりエスケープしたりをという処理を行う中に脆弱性がある。

対策としては、Client-side WAFのようなSite Firewallという仕組みを提案している。これは Firefox の Content Security Policy (CSP) に近くて、サーバ側からクライアントに対して、「このアプリからアクセスして良いサイトの一覧」をセキュリティポリシーとして通知する。Site Firewallではこれを見て、リスト以外のサイトへのアクセスを禁止する。セキュリティポリシーのコンテナとしてCookieを使ってるのが、少々変わっているところ。
PoCはFirefox Extensionとして実装。

感想：
Site Firewallの機能的にはCSPのサブセットのようなものなので、あまり新規性はないように見えるが、Cross-Channel Scripting という攻撃クラスを定義して、様々な攻撃パタンについて考察しているあたりがウケたのかなあ、と思える。