筆者はここ数年、ブラウザからの入力は指定された通りの正しい文字エンコーディングでエンコードされているか検証しなければならない、と解説しています。手前味噌ですが2006年3月に出版した「Webアプリセキュリティ対策入門」(技術評論社)でも、入力文字列のエンコーディングが妥当であるか検証しなければならない、と解説しています。
残念なことに最近になっても不正な文字エンコーディングが入力される可能性を考慮していないことによる脆弱性が、PHP本体自体やPHPも利用しているライブラリlibxml2に発見されました。不正な文字エンコーディングはデータが正しくないだけでなく、スクリプトインジェクションやSQLインジェクション、DoS攻撃等を可能にします。
マルチバイト文字エンコーディングは最初または前方に配置されたバイトで1文字が何バイトで構成されるか決まります。この性質を利用してマルチバイト文字列の開始バイトでエスケープ文字を無効化することが可能な場合があります。
Shift JIS等のマルチバイト文字に含まれる特殊文字(\)を利用し、余計なエスケープ文字を追加させ、文字列の終端を誤摩化す攻撃も可能になります。Shift JISやBIG5文字エンコーディングには\がマルチバイト文字列の中に現れます。このため、次の例のような文字エンコーディングを考慮しない文字列置換を行うと不必要なエスケープが発生します。
「表」は0x95, 0x5Cです。0x5CはASCIIの\です。addslashes関数でエスケープ処理すると0x95, 0x5C, 0x5Cとなります。これはSJISでは「表\」となり余計な\が追加されます。\がエスケープ文字のシステム(JavaScriptやMySQL)の場合、文字列が意図通りに終了せず意図しないコードの実行を許す場合があります。
SJISエンコーディングでは0x95はマルチバイト文字の開始バイトと解釈されるので、
を
と解釈してしまい、文字列が終了しないプログラムもあります。
PHPには文字エンコーディングが正しいか確認するmb_check_encoding()関数が用意されています。残念ながらmb_check_encoding関数を定義しているmbstringモジュールはデフォルトで組み込まれるモジュールでないため、海外で開発されたPHPアプリケーションのほぼすべてが文字エンコーディングが正しいかチェックしていません。
$_FILES以外の$_POST, $_GET, $_COOKIEに保存されたデータはすべて文字として扱えるデータである、とおおむね仮定できるので、ほぼ機械的に文字エンコーディングをチェックできます。しかし、アプリケーションによっては$_POST, $_GET, $_COOKIEに保存されたデータがバイナリである場合もあります。例えば、バイナリデータをURLエンコードでエンコードしている場合、PHPは自動的にデコードするので$_GETに保存された時点ではバイナリデータになっています。このような場合、文字列として文字エンコーディングチェックを行うとエラーが発生するので注意が必要です。このような場合、除外リストを作成して除外するとよいでしょう。
対策のまとめ
- 入力文字列は必ず文字エンコーディングが正しいか確認する
- 可能な限り文字エンコーディングは統一する
- SJIS、EUC-JP、ISO-2022-JPを取り扱う場合、特に注意する
- 正しい文字エンコーディングのみ保存可能な仕組み利用する(データベースなどのバイナリ型を利用して不正な文字エンコーディングの文字列を保存しない)