XSS Cheat Sheet
XSS Filter Evasion Cheat Sheet - OWASP
yohgakiさんのブログプログラミングではホワイトリスティングが基本からホワイトリストはどう作る?経由で知りました。先達多謝、というか自分が不勉強すぎ。
（追記：以下、XSS Cheat Sheetのページの主のRSnakeの言葉。
Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. 筆者より：XSSはcross site scriptingのこと。もし、XSSってどうやるのか知らないなら、このページはあなたの役にはたたないだろう。XSSの基本的なことについては理解しているけど、もっと詳しく知りたい、特にフィルタ(Web application Firewallなど）をだます手口について知りたい人向けのページだ。
This page will also not show you how to mitigate XSS vectors or how to write the actual cookie/credential stealing/replay/session riding portion of the attack. It will simply show the underlying methodology and you can infer the rest. Also, please note my XSS page has been replicated by the OWASP 2.0 Guide in the Appendix section with my permission. However, because this is a living document I suggest you continue to use this site to stay up to date.このページを読んでも、XSSに対する緩和法が書いてあるわけではないし、実際にクッキーやセッションを乗っ取る方法が書いてあるわけでもない。ここでは、ベースになるテクニックを紹介しているだけです。あとはご自分で考えてください。ところで、このページはOWASP(Open Web Application Security Project)のガイドの付録として(私RSnakeの承諾を得て)紹介されてます。とはいえ、このページは随時更新される可能性があるので、チェックは怠りなく。
Also, please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the page, however, if you have specific concerns about outdated or obscure versions please download them from Evolt. Please see the XML format of the XSS Cheat Sheet if you intend to use CAL9000 or other automated tools. 大抵のXSSのパターンは、このページにリストされているブラウザでテストされていますが、古いバージョンのブラウザなどでテストしたいときにはEvoltのサイトからダウンロードするといいかもしれない。CAL9000のようなテストプログラムでこのページの攻撃パターンをチェックしたい場合は、XMLの形式も用意してあるのでどうぞ。 追記終わり）
以下雑感
はてブにも書いたけど、こういった攻撃パターンはこれからも浜の真砂のごとく増えていくのは当然として、自分が想定した入力パターン(white list)が、これらのパターンのいずれに対しても脆弱でないということを機械的にチェックできないものかと、、(追記：↑にも書いたが、XSS Cheat Sheetのnoteの部分でCategory:OWASP CAL9000 Project - OWASPが紹介されているし、そのためにXML版のデータも提供されている）攻撃のパターンの中から、モンテカルロ法よろしく絨毯爆撃してもあんまり意味ないというか、何の確信も得られないので、たとえばLogicのシークエント計算のようにして、入力パターンと攻撃パターンの領域が互いに素であるということを、すべてとは言わないまでも、自明なケースについては枝刈りしてもらえれば、グレーゾーンはモンテカルロ法で、、という踏ん切りもつこうというもの（ぉぃ
ところで、正規表現から、それにマッチするパターンを生成するという話をいくつか読んだことがあるなぁ。
結局、想定する入力の領域をできるだけ絞ることができれば、うまくすればすべてのwhite listを数え上げて、それを攻撃パターンと一致するかどうか試せるわけだから、やっぱwhite listingのほうが分がいいよな。
Web application firewall(WFA)も、「行儀のいいwebサービス」の入力のガイドラインとして設定することができれば、とか、思うのだけど、それが実際どれくらい大変か、というのは、なかなか難しい。
アイデアとしては、デフォルトはキツめの制限を掛けておいて、必要があれば特定のパターンをバイパスしてもらうのはどうか、と思う。開発現場では、最初はフルオープンでテストしてみて、期待通りの動作を「することがあったら」、フィルタをかけてregression testをして、というパスが必要だろう。WFAで蹴られているのに気づかなくて、スクリプトのバグを疑ったことが何度もあるし、開発の段階では「壊れるまで負荷（攻撃）をかけて、どう壊れるかを知る」のも重要なテスト（というか、危険予知のセンスを磨く手段）だと思うから。
XSSはなぜ可能か
要するに、Webコンテンツの設計者が「ただのテキスト」だと考える入力の集合のうち、ブラウザやtaintedなデータを受け取ったプログラムがなんらかの応答をしてしまうようなパターン、もしくは受け手のプログラムがどんどん多様化を続けているってことも一因かもしれない。
サイトだけでなく、サービスの層をまたぐ（たとえばSQLインジェクション）とかも、このズレを利用していると言えるかもしれない。
Webサービスの多層化(MVCとか)だけでなく、ブラウザ側での処理能力の向上もあって、サーバ側で対処をしていても、フォームをチェックするJavascriptにちょっかいを出すような入力も現れているんだろう。事態は悪化していくんだろう。
だからこそ、正常なデータというものを限定する努力は怠れないということだろう。
その一方で、ユーザには窮屈さを感じさせてはダメなわけで、値は選択式するとか、コンテクストを限定する単純な選択をいくつかさせて、その他のデータは、過去の入力傾向や、似たような選好を持つ他人のデータから予測して提示するとかの工夫が必要になるんだろう。
