入力用のテストデータを設計するというのは、非常に重要なテスト設計ですね。皆さんは、どのようにテストデータを設計していますか。最も重要なテスト技法は、境界値テストです。しかし今回は、異なる観点でのテストとして「サニタイジングテスト」を紹介します。

サニタイジング（sanitizing）というのは、殺菌する、とか、衛生的にする、という意味です。主にWebアプリ開発の分野で使われるのですが、入力データが意図したものと別の意味で解釈されることを防ぐ技術のことです。もともとセキュリティ分野で使われている言葉ですね。ソフトウェア工学分野で、予防的／防衛的プログラミング（preventive / defensive programming）と呼ばれている概念と同じようなものです。

例えば
<script>alert('Not sanitized');</script>
という文字列を表示させるWebページを考えてみましょう。正直にこの文字列を書くと、実は文字列は表示されません。やってみて下さい。ダイアログボックスが開くと思います。理由は明らかですね。スクリプトのタグだと解釈されてしまい、文字列だとは解釈されないからです。この文字列を表示させようと思ったら、
&lt;script&gt;alert('Not sanitized');&lt;/script&gt;
と書かないといけません。"<"の代わりに、"&lt;"と書き換える必要があるわけです。この書き換えをサニタイジングと呼びます。

何が問題になるのでしょう。例えば入力された名前をそのまま表示するようなWebアプリ（占いなど）を考えてみて下さい。もし名前の代わりに<script>～</script>を入力したらどうなるでしょう。スクリプトが実行されてしまいますから、やり放題ですね。これは非常に重大なセキュリティホールになってしまいます。ですからリリース前に、サニタイジングがきちんと行われているかどうかをテストする必要があるのです。これが、サニタイジングテストです。

サニタイジングテストは、Webアプリだけに必要なテストではありません。例えば文字化けが起こらないかどうかテストする、というのは昔から行ってますね。海外製のアプリに2バイト文字を入力してみる、というのもサニタイジングテストの一種と考えてよいでしょう。基本的にはWebアプリに限らず、文字コード体系が複数ある言語の場合、ローカライズの場合、入力データに文字列だけでなく制御コードやスクリプト／プログラムが混在する場合、にはサニタイジングテストが必要です。

またWebアプリの場合、実害のないと思われるタグはサニタイジングしないことがあります。しかしIPAのサイトで紹介されているように、コメントタグやスタイルシートでの<BR>タグでも不具合は発生します。こうしたTIPSをいくつ知っているか、がサニタイジングテストの決め手になります。

Webアプリでは、入力データ以外も実はテスト設計の対象になります。入力データがそのままURLになって送られる（GETされる）場合は、URLの文字列を書き換えてWebサーバに送ってやるというテストも必要です。クライアントからは送られないかもしれませんが、セキュリティホールとしてクラッカーに狙われるわけですから。特にSQL文が送られるような場合（SQLインジェクション）や、ディレクトリ名やファイル名が送られるような場合（ディレクトリ・トラバーサル）は、致命的なダメージを食らう可能性があるので重点的にテストする必要があります。

意外に忘れやすいのが、リストボックスやHiddenフィールド、環境変数（HTTP_REFERERなど）、Cookieなどです。リストボックスは送られるデータが決まっていますし、Hiddenフィールドのデータはユーザから認識されないので、開発者はチェックしない可能性があります。環境変数やCookieなど暗黙で送られるものもチェックされないことがありますね。油断せず、サーバに送られる全てのデータについてテスト設計しないといけません。

サニタイジングテストの設計方針は簡単です。文字化けのように意図通り表示されなかったり、スクリプトやプログラムとして実行されるような文字列を、テストデータとして設計すればよいのです。しかしそれだけではテスト設計できませんから、サニタイジングテストで用いる代表的なテストデータを挙げておきましょう。

• 改行文字（システムによって異なることに注意）
  
• 円マーク（\）
  
• セミコロン（;）
  
• Webアプリのタグ（<,>,&）や引用符（",'）
  
• CSVを扱うアプリのカンマ（,）
  
• シェルやDB、OSのコマンド
  
• ディレクトリ名、ファイル名
  
• IDとパスワード
  
• conやprn、aux
  

もちろん、これで全部ではありません。テスト対象やミドルウェア、DB、OSの仕様をよく読んで判断して下さいね。