表1 HTMLのエスケープ処理

　アプリケーションの要件から見てエンコードが不要なフィールドまでHTMLエンコードするのは無駄に思えるかもしれないが，そうではない。HTMLエンコードに要する労力はわずかなものだし，すべての項目をエンコードすることによりチェックなどが容易になる。すべてをエンコードすると決めたほうが簡明でミスが少なくなるわけだ。逆に，ある部分はエンコードし，別の部分はエンコードしないという状態になると，かえって煩わしい。このため，Webアプリケーションを開発する際には，フレームワークなどに自動エンコードの機能を組み込むことが望ましい。

　このように，クロスサイト・スクリプティング対策の原則は単純そのものであり，難しいところは何もない。しかし実際には，多くのWebアプリケーション開発者に「HTMLエンコードの神話」が根付いており，このことが正しい対策の普及を遅らせているように思う。具体的には，

【神話1】HiddenフィールドのValue属性などはエンコードする必要がない
　もっとも古典的な「神話」はこれだろう。事実は，HiddenフィールドのValue属性値は変更できる^注2）し，GETパラメータやPOSTパラメータを改変したリクエストを別のユーザーに実行させることも可能だ^注3）。このため，Hiddenフィールドだけではなく，ラジオボタン，チェックボックス，セレクトボックスなどのValue属性も漏れなくエンコードしなければならない。

^{注2）例えばFirefoxのアドオン・ツールには，Hiddenフィールドの値を変更するための便利なツールがある。
注3）GETの場合はURLを起動させるフィッシング的な手法，POSTの場合は，HTMLメールを利用するか，いったん「わな」のページに誘導してそこからJavaScriptによりPOSTする。}

【神話2】クォート文字はエンコードする必要がない
　IPAが刊行している「安全なウェブサイトの作り方　改訂第2版」によると， 『HTMLタグを出力する場合は，その属性値を必ず「"」（ダブルクォート）で括るようにします。そして，「"」で括られた属性値に含まれる「"」を，HTMLエンティティ文字「"」にエスケープします。』 となっている。これは，タグの属性値以外のところでは「"」をエスケープしてなくてもよいように読める。実際，技術的には正しい指摘である。ただ筆者は，予防的処置として，どのような場合でも「"」のエスケープをお勧めする。

　その理由としては，

写真1　文字化けによるクロスサイト・スクリプティングの例 [画像のクリックで拡大表示]

という値をセットしてみる。すると，写真1のような画面が表示され，テキストボックスにマウス・カーソルがかかると，自動的にJavaScriptが実行される。写真はFirefoxで示したが，Internet Explorer(IE)やOperaでも同様の動作を確認している。また，文字コードはシフトJISがもっとも発生しやすいが，IEの場合，EUCでも同様の動作となった。

　なぜこのような現象が発生するのか。この例では，0x81というデータはシフトJISコードの1バイト目のグループに属するため，後続のダブルクォート「"」がシフトJISコードの2バイト目と解釈されている。このため，Value属性が「閉じられない状態」のままになり，表示項目中の「onmouseover」という文字列が，onmouseoverイベント・ハンドラと解釈され，JavaScriptを実行してしまう。この際，変数$p1のダブルクォート「"」がエスケープされていれば，このような事態は避けられる。

　この問題が発生する根本原因は何か？一つには，0x81という「単体では不正な文字」をそのまま表示したアプリケーション側の問題と言える。また，0x81とダブルクォート（0x22）の組み合わせはシフトJISとしてもEUCとしても該当文字はない^注4）ことを考えると，「あり得ない文字」の取り扱いに関するブラウザの問題とも言える。しかし，このような問題が現実に発生し得ること，クォート文字のHTMLエンコードにより予防が可能であることなどから，「どんな場合でもクォート文字をエンコードする」というルールにしておくのが予防的プログラミングとして安全である。

^{注4）後続文字がシングルクォート「'」(0x27)の場合も同様である。}

【神話3】Value属性値にHTMLエンコードすると，アプリケーション側でデコード処理が必要になる
　ネット上のブログなどを読んでいると，INPUTタグやOPTIONタグなどでValue属性値をHTMLエンコードすることについて，少なからず誤解が見受けられる。Value属性の値を利用するのはCGIプログラムやJavaScriptであり，これらのプログラムにはHTMLエンコードした値がそのまま渡されるので，アプリケーションやスクリプト側で元に戻して（デコードして）やる必要があるというのである。 　しかし，これは文字通り誤解である。理由は簡単。Value値のHTMLエンコードは

　なお，ブログやSNSなど最近のWeb 2.0的なアプリケーションの普及により，テキスト入力フィールド内でタグ文字（「<」や「>」）を入力する機会が増えてきているが，そのような場合にこそ，Value属性値のエンコード処理は重要である。そうしなければ，タグ文字類が正確に表示されないケースがあるからである。

【神話4】二重にエンコードするのが心配だ
　HTMLエンコードする際に，誤って二重にエンコードすると表示がおかしくなる。これは神話ではない。事実その通りである。 　しかし，このようなことが発生するのは，当然ながらHTMLエンコード自体が悪いのではなく，エンコードのやり方が悪いのである。エンコードのやり方を統一し，表示の直前に行うようにすれば，二重エンコードというミスはたいてい避けられるはずである。それでも混入した場合は，テストなどで検出して修正するしかない。それはほかのバグと同じことであって，HTMLエンコードを否定する理由にはならない。

【神話5】出力よりも入力の方が対応個所が少なくて楽だ
　確かに一般的なWebアプリケーションでは，出力時よりも入力時にチェックした方が該当個所をコンパクトにまとめやすい。しかし入力時チェックではアプリケーション要件を満たさないことは前回の記事で説明した通りである。開発効率の問題は，フレームワークなどで解決すべきものであって，間違った方法を採用することで効率を高めるのは不適切であろう。

【神話6】HTMLエンコードだけではクロスサイト・スクリプティングは完全には防御できない
　これもまた事実である。Webアプリケーションの設計・開発者はHTMLエンコードで対策できないケースについても知っておく必要がある。具体例とその対策については，次回改めて解説することにする。