おさかなラボ

書きかけだけどとりあえず公開。

要約版：「サニタイズいうなキャンペーン」とは from 高木浩光＠自宅の日記

クエリ文字列を変換すれば「サニタイズ済み」つまり安全、と思ってる人、多いんですかね。便利な言葉はしばしば人を思考停止に陥れる。

脆弱性を突く文字列の汚染源としては、

• クエリ文字列
• DB問合せの結果や、ログファイルなどからの取得文字列
• HTTPヘッダ(RefererやCookieを含む)
• セッションに格納されたデータ
• URLの一部

などなど色んなものがある。汚染を利用した攻撃の対象となる処理系も

• SQL処理系(e.g. SQLインジェクション)
• Webクライアント(Webブラウザ)(e.g. XSS)
• shell
• 処理言語自身(evalなど)

と様々なケースが考えられる。3番目や4番目は普通やらないだろうと思うところだが、巷のスクリプトの脆弱性を見てると案外多い。こういうものに頼る傾向はあまり宜しくないと思う。

汚染源は前述の通りクエリ文字列だけではない。また、汚染源はエンコードが施されてあったり、プログラム側で処理されたりするので汚染源を直接変換したからといって安全にはならない。高木氏も触れているが、変換や削除が新たな汚染を生むこともある。また、攻撃対象の処理系によって「何が危険なのか」が異なってくる(危険なのはメタ文字だけではない)ので個別に対応する必要がある。「クエリ文字列をエスケープしただけ」で安全になるわけがないし、「サニタイズ」という一定かつ確実な方法があるわけでもない。

汚染源が何であろうと、安全でない文字列は攻撃対象となり得る処理系に渡される「直前」に「的確な」検証を行わないと確実な対策とはならない。

これも高木氏も触れられているが、汚染された文字列が、処理系に使われる直前に検証される様子が簡単に見渡せるコードを書くように努めることは脆弱性を埋め込む可能性を下げる。値が何に対して安全であるかを示す変数名を使うのも手だ。HTML出力用に変換した文字列をそのままSQL問合せに突っ込んでセキュリティ・ホールを作っている例を見たことがあるが、こういった事態は起こりにくくなるだろう。

$form = new myForm;
$sql_safe = $form->getSqlSafe();
$sql = "select name from user where uid = '{$sql_safe['uid']}'";

この場合、$sql_safeの安全性はmyFormクラスの設計に依存するのでコードを見渡しやすくなる。もちろん次のようなコードは論外だ。

funciton make_sql($sql_safe){
    return "select name from user where uid = '{$sql_safe['uid']}'";
}

誰がどのようにmake_sql()を呼ぶか全く分からないので、$sql_safeが安全だという保証はどこにもない。眉間にマジックで「ハンサム」と書いてハンサムになった気でいるのと同じくらい間抜けだ。また、

• 処理系に渡される文字列(SQL問合せ文など)に、得体の知れない変数がボコボコ埋められている
• あるいは文字列置換関数などでぐちゃぐちゃにいじっている
• shell渡しやeval系の処理(perl-regexの’e'オプションを含む)に依存する

なんて状況は絶対に避けたいところだが、残念なことにこういったコードは結構多い。

カテゴリー » Web Prog., Security
投稿日 » 2006/01/11 水曜日 - 08:33:22 by かなだ
コメントはこちらからどうぞ。ご自身のサイトからトラックバックを利用する場合は以下の URI をご利用ください。

http://kaede.to/~canada/doc/never-say-sanitize/trackback/