んっと。この情報を得たルートをたどると
セキュリティホール memo さん 経由 http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2006/02.html#20060212_addslashes
hoshikuzu | star_dust の書斎 さん 経由 http://d.hatena.ne.jp/hoshikuzu/20060211#P20060211PHPSQLINJECTION
t_komuraの日記 さん http://d.hatena.ne.jp/t_komura/20060122#1137944280
内容なのですが……状況によってはかなりしゃれになってないかも。
文字コードが Shift_JIS(より正確には「文字の最後に￥が出てくる可能性のある文字コード」)の場合、addslashes()で文字列をスラッシュでクォートしてSQLインジェクション対策〜…ってやってるはずがダメポかも、というお話です。
…さらっと流すにはちょっと重たいニュースですねぇ。
ちなみにそれにからんで、悪名高き(ってことにしたい)php.iniの、magic_quotes_gpcってディレクティブについても触れられています。
magic_quotes_gpcってのは「オンの場合、全ての' (シングルクオート), " (ダブルクオート), \ (バックスラッシュ)およびNULL 文字がバックスラッシュで自動的にエスケープされます。」って感じのぶつ。…正気の沙汰じゃないなぁ。
自動的に処理ってのが気に食わないのも一点なんだけど、個人的には「サニタイズは直前に。ご利用(出力形態)にあわせて計画的に」主義なので。「入力時に捕捉＆サニタイズ」には弊害と問題しか感じ得ないです。
ついでにそもそも論からいえば「そもプログラム内部の情報としてShift JISなんて物騒な形式のブツもっちゃだめだよねぇ」って話もあり。旧来のプログラマ的には、取得した瞬間にEUC(最近ならUTF-8かな？)に変換するのは、脊髄反射レベルで身に付けるべきお作法だったように記憶しているのですが。っつかまず「入力文字列がどうなっているのか」って考察からとか。
この辺にもphp.iniの自動化による弊害を感じてしまいますです。
