AjaxのXSS対策

セキュアスカイ・テクノロジーのCTO福森さんの記事がでていますね。
第1回 Ajaxとクロスサイトスクリプティング：ここが危ない！Web2.0のセキュリティ｜gihyo.jp … 技術評論社

初回はWeb2.0の中核技術ともいえるAjaxを見ていきたいと思います。
Ajaxのセキュリティについて考えていきますが，その前にAjaxについて簡単におさらいしてみましょう。

AjaxとはAsynchronous JavaScript XMLの略であり，【後略】

高木さんのはてブには

説明が下手。精進してちょ。

と、いつになく優しいコメント(?)がついています。福森さんは顔見知りでなかったのか、はてまた単に忙しかっただけか・・・
というのも、この記事、突っ込みどころが満載なのですが、少しだけ指摘してみます。

1ページの末尾には、

つまり，contents.cgiでクロスサイトスクリプティング対策が行われていなかったということになります。このように不正なスクリプトを入力されたとしても，それをそのまま出力しないでエスケープ処理を行ってから出力することが，クロスサイトスクリプティング対策になります。

とあるのですが、エスケープ処理をするのがcontents.cgi側なのか、クライアント側のJavaScriptなのかがはっきりしません。どちらでやってもXSS対策にはなりますが、基本的な前提ですので明確にしておかないと分かりにくくなると思います。「contents.cgiでクロスサイトスクリプティング対策が行われていなかった」とある以上は、CGI側(サーバー側)でやっとけということなんですかね。
しかし、CGI側でHTMLエスケープするというとは、HTMLデータをやりとりするわけだから、AjaxというよりはAHAH(Asynchronous HTML and HTTP)に近いんじゃないですかね。

一方、2ページ目には、こうあります。

これは，Internet Explorerがファイルの中身を見て，その中にHTMLっぽい文字列が含まれていればHTMLだと判断するということを意味しています。このため拡張子やレスポンスに含まれるContent-Typeヘッダとは関係なく，外部から参照可能なファイルにはクロスサイトスクリプティング対策が必要であるということになります。
【中略】
このように，Ajax経由でアクセスさせることを想定しているファイルであっても，ブラウザで直接アクセスされた場合のことも想定しておく必要があります。

なぜブラウザで直接アクセスされた場合のことを想定しなければならないかが説明されていないので、分かりにくい文章になっています。
この文の下には、クラッカらしき人が「ファイルへ直接アクセス」する様子が図示されていますが、XSSで想定すべきシナリオは、クラッカに誘導されて正規ユーザがファイルへ直接アクセスしてしまう状況のはずです。引用したあたりの文章を著者名を伏せて読んだら、「この筆者、XSSのこと理解してないんじゃないか」という疑念がわきそうですが、まさか福森さんがXSSを理解していないはずがないので、「説明が下手」というコメントになるのでしょうね。

さらに言えば、直接アクセスされるケースに対して、どう対策するのかは明記されていません。これまでの文脈からは、ひょっとしてHTMLエスケープしておけということなのかなぁという気もしますが、正当なAjaxの使い方(データスキーマをきっちり定義する)からは外れたやり方のように思います。それも、憶測に過ぎません。
では、どうするのがよいか。このテーマは興味を持っている内容なので、余裕ができたら書いてみたいと思います。