前回の内容はいかがだっただろう。今回の内容を述べる前にひとつ補足がある。前回および今回の内容はサイトの脆弱性をチェックするより前の段階の話であるということだ。チェックはあくまで「確認」であり、設計やコーディングが正しく行われて初めて実行する意味がある。
脆弱性は正しく設計やコーディングができていないからこそ生じるのであって、そもそも正しく構築されているのであれば出現しない「はず」だ。“はず”というのは、ケアレスミスをゼロにすることは不可能であるからで、そのミスを発見するのがチェックの目的となる。
脆弱性は、設計やコーディングのミスの結果でしかない。そのミスを正せばおのずと脆弱性もなくなる。それでは、ウェブアプリケーションの「正しい」コーディングとは何であろうか。今回は、それを説明する。
コーディング時に発生する脆弱性
コーディング時に発生する脆弱性の原因は2つ考えられる。ひとつは入力時のデータ検証の不足であり、もうひとつは出力時のデータの処理不足だ。入力、出力どちらの場合でも扱うデータの形式は設計段階で規定されているはずであり、範囲外の値を受け入れたり出力したりするのは「実装＝コーディングのミス」と言える。
入力時のデータ検証の不足
これは、ウェブアプリケーション自体が処理するデータが想定する範囲に収まっているか検証していないことによるものだ。サーバに送られるすべてのデータはユーザーによって改変できる。たとえば、ドロップダウンリストで指定される値やhiddenフィールドの値など、単にブラウザを用いているだけでは変更できないパラメータの値であっても容易に変更が可能だ。
このとき、値が意図しているものであるかどうか確認を怠ると、アプリケーションが全く意図していない動作を行うことがある。これを防ぐためには受け取ったデータの変数型や値のとりうる範囲を確認し、型が異なったり範囲外であれば再入力を要求するなどエラー処理を行えば良いということになる。
これを行わないとディレクトリトラバーサルやバッファオーバーフロー攻撃が成立する可能性がでてくる。
一点注意してほしいのは、この入力データの検証は、ウェブアプリケーションの機能を正常に動作させるために必要なのであって、SQLインジェクションやクロスサイトスクリプティング(XSS)など、出力データの処理不足が原因で起きる脆弱性を防ぐものではないということだ。
結果的にそのような攻撃を防ぐことはあるが、これをもって対策と考えることは危険だ。これについては次項でも述べるが、インジェクション系の攻撃が成立してしまう原因はメタキャラクタを受け入れたためではなく、そのメタキャラクタをそのまま出力してしまっていることにある。
出力データの処理不足
代表的なものは、前述のXSSやSQLインジェクションとなる。これらは、ウェブアプリケーションが出力するデータ中にそれを受け取る別のプログラムにとって意味のある特殊な文字（メタキャラクタ）が混入することにより、攻撃者が意図した処理が実行されてしまうというものだ。
ここで別プログラムと言っているのは、データベースであったり、ウェブブラウザであったりする。出力といえば、リクエストを発したものに対するレスポンスだけを指すように錯覚してしまうことがあるが、ウェブアプリケーションの外部へデータを出力しているのであるためデータベースに対するSQL文の発行も出力になる。
ここで重要なポイントは「それを受け取るプログラムにとって意味のある」という個所になる。HTMLにはHTMLの、JavaScriptにはJavaScriptの、SQLにはSQLのメタキャラクタが存在する。
逆に言えば、ウェブアプリケーション内部変数に入力された値としてそれらのメタキャラクタが含まれていても害にはならない。それらの値がそのまま外部のプログラムに渡ったとき、初めて問題となる。これが、出力時の問題とする理由だ。対策としてはエスケープ処理の実行となる。
出力時の問題としても、結果的に正しく出力されるのであれば入力時に処理を行っても良いのではないかと考えられるかもしれない。しかし、入力時にそのような処理を行うと非効率であるばかりか弊害が多くでる。これについては産業技術総合研究所の高木浩光氏が「サニタイズ言うな！」として解説をしているのでそちらを参照してほしい。
