ウノウラボのセキュリティ意識
エスケープ処理を行うのは、通常HTMLのレンダリングする場所ですが、上記のようなJavaScript経由でないアクセスも考慮に入れる必要があります。
HTTP上にエスケープしていない文字で通信する場合には、Ajax経由でないアクセスのこともHTTPのBODY部分ではなく「HTTPヘッダに入力するタイプのJSON」などを使うべきです。
Ajaxだけしかアクセスしねぇやーとか思ってると、罠のURLを踏んだユーザがアクセスしてしまう場合があります。
そんな心配する前に JSON の Content-type を text/html 以外にするのが先じゃないですか。まぁ、IE だとファイルの内容を見て勝手に HTML として処理することもあるみたいなので、一概にそれだけで OK とは言えないけど。
また、JavaScriptによるWYSIWYGで生のHTMLを操作できるライブラリなどを作成したり利用したりする場合には、それ自体にXSSが存在しないかどうか注意深く調査する必要があります。
「XSSで攻撃される可能性がある/XSS脆弱性が存在する」ということを「XSSが存在する」というのかな？激しく違和感を感じるのは自分だけだろうか。
もちろんサーバサイド側で全部エスケープ処理を付すのが一番楽だと思います。
楽といえば楽だけど、保守性の面で心配。
たとえば、登録フォームにバリデータとして登録されているメールアドレスやIDかをチェックして「このIDは登録できます。」などと表示するといった処理を行うときには注意が必要です。 なぜならば、そのチェック処理を行うサーバサイドのインターフェースに、スクリプトなどで直接大量のIDを流し込むことにより容易にそのIDが使われているかチェックすることができます。
とはいえ、既存の登録フォームでも、スクリプトを流せばチェックできるものもありますので(CAPTCHAである程度は防衛できそうです。）リスクとしてはクリティカルではないと思いますが、技術者としてはベストプラクティクスを用意しておきたいものです。
後段の、「既存の登録フォームでも、スクリプトを流せばチェックできるものもありますのでリスクとしてはクリティカルではないと思います」って論理がやばすぎる。意味が分からない。
たとえば、潜在的に SQL Injection が出来るページってのは大量にあると思うのだが、だからといって SQL Injection 脆弱性がクリティカルじゃない、なんて結論はでないわけで、リスク評価に「他のところでも出来る」なんて要素を持ってきてどうするよ。
蛇足だが、メールアドレスの存在確認には登録フォームだけでなく、パスワードリマインダが使えてしまうケースも少なくないと思う。
