XSS穴に関する基本的な考え方

JavaScriptというか、ブラウザサイドスクリプトを起動できる記述ってのは、俺が思いつく限りでは以下の4パターンある。

1.scriptタグ内にコードを書く

2.タグのイベントハンドラにコードを書く

3.aタグのhref属性にjavascript:に続いてコードを書く(これはユーザーのクリックが必要)

4.外部ファイルを自動的に読み込む書式要素に、javascript:に続いてコードを書く

1、2、3はパターンマッチでつぶすのもそんなに難しくない(コントロールコードとかが絡まなければ)けれども、4がかなりやっかいだ。

外部ファイルを読み込む書式要素ってのは、たとえばlinkタグやframe、iframeがある。その辺りはまだHTMLタグの範囲として気がつきやすいのだが、スタイルシートの範囲まで考えると、スタイルシートで外部イメージを読み込む書式とか、同じくスタイルシートで外部スタイルシートを読み込む書式なんてところでもJavaScriptが有効だ。

私はJavaScriptにもスタイルシートにもあまり詳しくない(自分が使いたいところしか覚えていない)ので、以上のポイントくらいしか思いつかないが、JavaScriptスタイルシートも仕様を隅から隅まで眺めると、ほかにも穴になりうる部分が見つかるかもしれない。また、スタイルシートのようなHTMLの拡張が今後新しく出てくる可能性は少なくないし、その際にはその拡張と絡めてXSS穴が新しく生まれる可能性は十分にある。たとえばブラウザサイドスクリプトには、IEならばJavaScript以外にVBScriptがあるわけだけど、今後のIEではもしかしたらCSharpScriptとかJSharpScriptなんてのも出てくるかもしれない。その際に現在想定していない新しい表記法でそれらを呼び出せるようになる可能性がある。

ところで、1、2、3のパターンに関してはパターンマッチでつぶすのは難しくないと書いたが、それはあくまでもプログラムを作る際にはじめから「あらゆるユーザーからの入力は信用しない」というポリシーをもっていた場合に限る。基本的に信用しつつ書いたコードを、後から「危険そうな部分だけをつぶしていく」といった対処を取った場合は、1、2、3のパターンに関しても穴ができやすい。こちらは理論的な穴と言うよりは人間的な穴といった感じで、4のバリエーションの話とはちょっと違うけれども、完全につぶすのが難しいという意味では4と同等だ。一度作って動いているプログラムを、もう一度ゼロからセキュリティに気を配って作り直すのは(人間的に)大変だし。

やっぱまだ抜けがあった

主だったところはほとんど塞いであるけれども、まだ本文中にスタイル定義を書いたときの穴が残っているみたい。ほとんど塞いだと思っていても、地道にいろいろなパターンの組み合わせを試していくと、新しい穴が見つかっちゃうんだよなー。

使えるタグを絞る

先日より続けてまいりましたXSS脆弱性についての対策ですが、本日、日記文中、及びヘッダ、フッタでご利用いただけるHTMLタグを限定する措置を行いました。

XSS脆弱性について5

*

使えないタグ要素をつぶしていくのではなく、使えるタグを選んでそれ以外はすべてダメって方ならば、チェック対象が絞りこめるんで完璧な対処も不可能ではなさそう。そういうやり方ならば、HTMLタグOKなシステムでもなんとかなるのかな?

はてなダイアリーWikiとの違い

Wikiでは「キーワード=一つのドキュメントのタイトル」であることが基本である。そして、すべてのドキュメントは基本的にフラット(公平)に扱われる。

しかし、はてなダイアリーでは日記ドキュメントとキーワードドキュメントは完全に違ったものとして扱われている。はてなダイアリーWikiを日記風にしたシステムではなく、一般的な日記システムとは別に、Wiki風のキーワード指向ドキュメント管理システムを用意し、二つのシステムを自動リンク・検索によって結びつけたものだ。

はてなダイアリーと連携しているキーワード指向ドキュメント管理システム自体も、一般的なWikiとは違っている。このシステムは、Wikiのようにキーワードに結びついたドキュメントを管理するだけでなく、キーワード自体を管理する機能が強化されており、結果として辞書的な利用方法に適したものとなっている。

キーワード自体を管理する方法としては、まずキーワード自体に「固有名詞」「普通名詞」という分類がある。また、キーワードは階層構造をもち、キーワード自体をカテゴライズすることができるようになっている。またキーワードにはドキュメント本文(フリーワード)を結びつけられるだけでなく、より具体的な属性(型付けされた情報)を設定することが可能になっている。