2008年8月23日(土曜日)

対策としての入力値チェックは……

まっちゃ445の懇親会で、大垣さんと徳丸さんとのやりとりが話題になっていました。

ホワイトリストはどう作る? (blog.ohgaki.net)
ホワイトリスト方式の優位は神話 (www.tokumaru.org)
プログラミングではホワイトリスティングが基本 (blog.ohgaki.net)
プログラミングではホワイトリスティングが基本ではない (www.tokumaru.org)
今こそXSS対策についてまとめよう (www.tokumaru.org)

……なんというか、何について議論されているのかがよく分からない感じがしますね。

徳丸さんは以下のように述べられていますが、

入力値チェックはアプリケーションの仕様に従っておこなうしかない。

以上、今こそXSS対策についてまとめようより

これは「ホワイトリストかブラックリストか」という以前の話で、そもそも入力値チェックをXSSの「対策」とすること自体が不適切なのだ、と言われているのだと思います。これはその通りだと思います。

たとえば、このサイトには掲示板があり、コメントを書くことができます。そこで入力されるコメントに対して、どういう入力値チェックを行うことができるでしょうか。ちなみに、このサイトではHTMLの書き方やXSS脆弱性の攻撃パターンについて議論されることがありますから、<script> などが含まれていたらエラーにする、という処理をされては困ります。

結論としては何でも書けて良いわけで、あえて言うなら制御文字を取り除いたり、長さチェックをしたりするくらいでしょう。もちろん、これらはXSS対策ではなく、「アプリケーションの仕様」によるチェックに過ぎません。

……というわけで、このようなケースでは、そもそも「入力値チェックで脆弱性を防ぐ」なんてことは一切できないのですね。では脆弱になるのかといえば、そんなことはありません。単に、入力された内容を#PCDATAの内容として問題ないように、< を < にしたりして出力すれば良いだけです。

※もちろん、#PCDATA でないところに出力する場合は別な処理が必要になることがあります。

入力値チェックをしなくても、XSSは防げるのです。必要なのは、HTMLを正しく表示することだけです。

しかし、入力値チェックでXSSを防がなければならないようなケースも存在します。それは、入力されたHTMLを文字列として表示するのではなく、マークアップとして有効にしようとしているようなケースです。その場合、<em> は OK だが <em onclick="……"> は NG とする……といった複雑なチェックが必要になってきます。これは脆弱性対策のための入力値チェックだと言えるでしょう。

※もっとも、この場合にも、どのタグを許可するのかは仕様で定められるでしょうから、アプリケーションの仕様に従ったチェックをするだけであるとも言えます。

……と、ここまでが通常の前提の話。最近ではこれに加えて、「アプリケーションがちゃんと作られている自信がないから、予防的対策として……」という微妙な話があったりします。この場合、アプリケーションやWAFによって入力値チェックが行われますが、あくまで予備的なものです。本質的な部分の話ではないということに注意する必要があるでしょう。

※こういう対策をするべきのなのかどうか……という議論もあるでしょうが、まあここではその議論は置いておくとしましょう。

まとめると、XSSと入力値チェックとの関係には、以下の3つのケースがあるのではないかと思うのです。

通常のケース: 基本的に、XSS脆弱性を防ぐために入力値チェックは必要ない。
特殊なケース: タグをマークアップとして有効にするようなケースでは、入力値チェックをしなければならないことがある。
予防的対策: 本質的でない部分で、予防的対策として入力値チェックが行われることもある。

最初のケースについてはそもそもチェックが不要なのですから、ホワイトリストもブラックリストも関係ありません。ホワイトリストかブラックリストか、という話は後二者に関連してくる話ですが、特殊ケースにおけるチェックと、予防的対策におけるチェックではまた事情が異なってくると思います。

このあたりがもう少し整理されると、議論が分かりやすくなったりするのかもしれません。

「対策としての入力値チェックは……」へのコメント (1件)

関連する話題: セキュリティ / まっちゃ445勉強会

第01回まっちゃ445勉強会: ライトニングトーク

ついカッとなって第01回まっちゃ445勉強会 (sites.google.com)に参加してみました。

まずは午前中のライトニングトークについて、ぱらぱらとメモ。ただし、ディスカッションの内容は非公開ということになっていますので、質疑応答の内容は記載していません。

あまり知られていないXSS攻撃のバリエーション～XSS脆弱性に対しXHRを用いた攻撃

hnwさん (d.hatena.ne.jp)によるお話。

XSSの脅威として、よく「ターゲットのドメイン上で任意のスクリプトが実行できる」ということが言われます。その「任意のスクリプト」の一例として、ターゲットのサイト上で XMLHttpRequest を実行するというパターンのご紹介。

JavaScriptでダミーのページ遷移を実装し、XMLHttpRequest でターゲットの本物サイトから本物のページを読み込んで、アンカーとログインフォームだけ書き換えて表示。本物サイト上のあらゆるページ遷移がきちんと再現される上に、ログインフォームにはもれなくパスワード奪取の罠がついてきます。

ログインフォームの存在するページに脆弱性がなくても、あとから追加したキャンペーンページが脆弱だったりすると、そこを起点に攻撃ができてしまいます。難点は、アドレスバーが書き換わらないこと。

実際にこういう攻撃が行われるかどうかは何とも言えませんが、ターゲットのサイト上で XMLHttpRequest を実行することができるという発想は重要だと思います。いろいろなことに悪用できそうです。

※最近、某届出に「管理画面のページ上の情報を読み取ることも可能であり、一般的なCSRFの攻撃よりも……」なんてことを書かせていただきましたが、まあそういうことですね。

「ISMS審査員補更新手続」狂想曲

F.koryuさんのお話。

ISMS審査員補は3年ごとに更新登録が必要なのですが、更新には一定時間の教育の受講という要件があり、しかもその一部は相互啓発を伴うものでなければなりません。相互啓発というのは、研修、セミナーの受講、学会への参加などのことです。

要は、更新時期が来たら突然「過去3年間のセミナー参加の証左を集めろ!」というミッションが発生するというお話ですね。まっちゃだいふくさんにお願いしてまっちゃ139勉強会の受講証明をもらったりとか、そういうミッションです。:-)

おさえておきたいIE8のセキュリティ新機能

はせがわさんのお話。

最初に「IEとFirefox、どちらが2.0的か?」という問い。あとはIE8の新機能のお話。以下列挙。

XSS Filter: 明らかな攻撃的スクリプトをブロック
Cross Document Messaging: iframe間でメッセージのやりとりを実現する仕組み。クロスドメインで通信可能で、双方向のメッセージ送受信が可能。JSONPより安全にクロスドメインでのデータの受け渡しができる
XDomainRequest: クロスドメインで読み込み可能な XMLHttpRequestのようなもの。サーバ側で HTTP応答ヘッダに XDomainRequestAllowed: 1 を入れている場合のみ読めるという仕組み。Flash の crossdomain.xml は許可ドメインリストを見られてしまったり、いろいろ嫌な問題がありますが、この仕組みならそういう問題はないですね。
toStaticHTML: HTML断片から「動的」な部分 (script要素など) だけを削除する。要は HTML メールのフィルタのようなもの。
JSONパーサ: JSON データを読み込んでオブジェクトに格納する。今までは eval したりしていたので、外部サイトの JSON データなどを拾ってくる場合は何が実行されてしまうのか分かったものではありません。これを使うと、純粋にデータの読み込みだけが行えます。
Content-Type無視の改善: Content-Type が image の場合はHTML扱いしなくなりました。また、Content-Type: text/plain の場合には、authoritative=true をつけると無条件で text/plain とみなします。

Content-Type無視はXSSの巣窟なので、これが改善されるのはありがたいですね。