最近Cookieを使ったSQLインジェクションが発見されたということでその手法の詳細記事がありました。前置きが長すぎてもっと簡潔にして欲しかったのですが問題点は以下のようになります。
- メジャーな侵入検知システムはPOST/GETの検査を行うがCookieを見逃していた。
- スクリプト側でPOST/GET等メソッドを明示的に区別してデータ取得していない。
- スクリプト側で入力データの検査が出来ていない。
元記事には
ここまで聞くと、「うちのサイトではクッキーにデータベースに関連するような情報は格納していないから関係ない」と、早合点する人もいるかもしれない。それは間違いなので、もう少しお付き合いいただきたい。
なんて書いてるからよくよく読んでみましたがCookie使う以前の問題で仕事でウェブプログラミングしているならその会社のスキルを疑って良いレベルです。PGのスキル不足は常にあると仮定してもレビューせずに素通りかPLが無能。PMが放置主義って言ってる様なもので会社でレベルで恥かいてるぞ。私ならこんな杜撰なコード組む会社に2度目の外注はしない。
まずコードの品質を上げる前に侵入検知システム等に頼るのは気が進まないし費用のムダ。これの方法の恐いのは侵入検知システム自体に穴がある場合だけでなく、サーバー移設等環境が変わった場合にミスが起きやすい。ニュースで「サーバーの設定ミスで情報漏えい」というケースがこれ。
次にデータ取得においてメソッドを区別していないのはCookie以前の問題でGETしか想定していないスクリプトでPOSTで渡されてもスクリプトのみでは同じ問題が起きるので注意すること。昔Perlで外部ライブラリなしでコーディングしているときは非常に面倒だと思いつつもどうやってデータがウェブサーバに送られてくるのか勉強になりました。今時よく利用されるASPやPHPはその辺の面倒な処理を自動的にやってくれて組込関数グローバル変数から読み込めますがRequest系の実装は気持ち悪くて使えない。未だにRequestについてGET/POSTを気にせずどっちでも使えるから便利とか発言するPGを見かけるが変数名が重複したときの対処方法を考えていないのが大半。セキュリティはともかくバグの元になる事を想定できていない。そういう人に限ってデバッガ未経験だったりする。
あとニュース記事には書かれていませんがPHPの場合、Requestでなくても$_POSTや$_GETのみで変数を上書きできるから注意ですね。通常リスト構造のデータを受け取るときは配列型にしたほうが便利ですが、それをせず同じ変数名で並べて送ってくるフォームがありそれにも$_POSTや$_GETは対応できないのでPerlの時のように素の入力データから抽出しています。それと同じ方法で本来の変数を上書きされても発見できない場合がありますので注意です。
最後に入力されたデータを検査していないのは論外、今回のセキュリティホールもPOST/GETを想定した変数だとしてもスクリプト側で検査していれば問題になっていない。メソッドを明示していればCookie経由で上書きしようとした変数はその場でイジェクトできるし、Request受けていてもそのデータを検査できていれば良いのである。とは言っても現実はApacheエラーログを見ずに組む人が多い、サニタイズどころかValidateやisset検査すらせずにエラーログを汚しまくる奴もいる。指摘するとErrorじゃなくてWarningだから大丈夫だろうとか言葉を理解できていない人やErrorじゃ無いんだからサーバー側でログ出力止めろよ！と逆ギレする民度の低いPGも少なからず存在する。そういうのに限ってこれまたPHPはPerlと違ってセッション実装できているから凄いとか内部処理を知らずに自慢(それもPHP作った本人じゃないのに)していたことがあって呆れたこともあります。
以上で愚痴込みのまとめは終わりますが、元記事を見てハッと気付いた脅威が一つありました。
最低限の作業として送られてくるデータは特定して検査するように書いているつもりですが、セッション変数はサーバーに保存されているデータなのでそこまでは強制的に検査していませんでした。(ヒマがあればするけれど他人にまで強制していない)
これの何が原因かというと、一度送られたフォームデータ(特にショッピングカート等)は途中ページでの改ざんを防ぐ為にセッション変数として保持することがありますが、保存したセッション変数からデータを再取得するときに検査をしていない場合がありました。近年はCookieに値セットして使うことが無いので完全な見逃しですが、Cookieを改ざんされた時に$_SESSIONが自動的に汚染されないか確認したことが無かった・・・。これは週明け直ぐにでもチェックしてみます。
他にDBとの入出力に対しての検査も、最初はそこまでする必要あるのかな？と思っていましたが仕事で使う内に必須だと思うようになりました。セキュリティ的には外部と接触する部分で一斉検査すれば大体良いのですが、開発途中でDBのデータがいい加減に入力されているとか仕様外の構成になっていたりするとが多く、というかほぼ100%でデバッグの障害になってたりもします。これでPGとDBエンジニアが鶏が先か卵が先かみたいなケンカもします。そこでスクリプト側としてはDBとの入出力にも開発効率を上げるために検査を入れておいたほうが良いと思います。あとApache管理者の意見として、大量のUndefined indexでログを汚すなというのもあります。
またまた進化したＳＱＬインジェクションの脅威 クッキーを悪用 セキュリティー-最新ニュース:IT-PLUS
http://it.nikkei.co.jp/security/news/index.aspx?n=MMIT2g000028102008&cp=1