Web ベースのアプリケーション(CGI スクリプトのような)は、信頼できるサーバ 上で稼働し、何らかの方法で Web 経由で入力データを受け取る必要があります。 入力は概して信頼できないユーザから来ますので、この入力データを検証する 必要があります。 実際、情報は信頼できない第三者からやってきます。Section 6.15 にさらに詳しい情報があります。 たとえば、CGI スクリプトは、情報を標準的な環境変数や標準入力を通じて取得 します。このドキュメントの残りの部分では、CGI にターゲットを当てて論じる つもりです。理由は、CGI が動的に Web コンテンツを実行する最も普及している 技術であり、他の動的に Web コンテンツを実行する技術も一般的な問題点は同じ だからです。
CGI からの入力の多くが、いわゆる「URL エンコードされた」形式になっている 点が、検証をより厄介にしています。つまり 16 進数の HH というバイト値を表す には %HH という形式をとります。 CGI や CGI ライブラリは、これらの入力を適切にデコードして、バイト値が正しい かどうかをチェックする必要があります。 %00(NIL)や %0A(改行)のような疑わしい値を含むすべての入力を 間違いなく処理しなければいけません。 入力のデコードは繰り返し行わないでください。そうしないと、「%2500」の ような入力が、誤って処理されてしまいます(まず %25 が「%」に変換 され、その結果「%00」が間違って NIL キャラクタに変換されてしまいます)。
入力に特殊なキャラクタを混ぜることで、CGI スクリプトを攻撃するケースがまま 見られます。上記の解説を見てください。
Web ベースのアプリケーションで扱うデータ形式がもう 1 つあります。それは、 「クッキー」です。 このクッキーもユーザが勝手に値を提供できるので、予防策を特別に取らない 限り信頼できません。 また、クッキーはユーザを追跡するのによく利用され、ユーザのプライバシーを侵す かもしれません。 結果として、ユーザはクッキーを無効にしてしまう場合が多く、Web アプリケーション はクッキーを必要としないように設計した方が良いでしょう(しかし、個々のユーザを 認証しなければいけないとした以前の議論を見てください)。 永続するクッキー(現在のセッションだけでなく、それ以後も存続するクッキー)の 利用を避けるか、制限をかけることをお薦めします。クッキーは簡単に悪用されて しまうからです。 実際現状では、米国の政府機関は永続するクッキーを特別な例外を除いて禁止して います。 ユーザのプライバシー侵害が心配だからです。 OMB guidance in memorandum M-00-13 (June 22, 2000) を見てください。 クッキーを使用する上で注意しなければいけないのは、ブラウザの中にはプライバシー・ プロファイル(サーバのルートディレクトリにある p3p.xml がそれです)を必要と するものがあるかもしれません。
HTML のフォームにはクライアント側での入力チェックを入れて、これで不正な 値を防御するものがあります。これらは普通、Javascript や ECMAscript、Java で実装してあります。 このチェックは、ユーザにとっては役に立ちます。ネットワーク経由でアクセス しなくても、「すぐに」チェックができるからです。 しかし、この種の入力チェックは、セキュリティの点からすると無駄なチェック です。理由は、攻撃者は「不正な」値をチェックを受けずに直接 Web サーバに送り つけられるからです。 このチェックを駄目にするのでさえ、難しいことではありません。Web アプリ ケーションに対して、任意のデータを送るようなプログラムを書く必要はありません。 一般的には、サーバは入力チェックをすべて自前で行う必要があります(フォームの データやクッキー等)。サーバは、クライアントがしっかりしているとは信じられ ないからです。 つまり、クライアントは一般的に「信頼に足る伝達経路」ではないからです。 信頼できる伝達経路については、Section 6.11 に さらに情報があります。
Microsoft の Active Server Pages(ASP)を使って入力の妥当性を確認する議論に ついては、Jerry Connolly 氏が http://heap.nologin.net/aspsec.html で簡潔に論じています。