PEAK XOOPS - Which function should be adopted in escaping string? in englishin japanese

Archive | RSS |
PHP
PHP : Which function should be adopted in escaping string?
Poster : GIJOE on 2006-05-25 06:34:07 (18487 reads)

in englishin japanese
This is a summary of discussion with ELF about escaping string for SQL.

I recommmend addslashes()

(A) performance
(B) compatibility with environments of magic_quotes_gpc=on
(C) reverse function exists
(D) DB connection free

ELF recommend *_escape_string()

(1) clear the purpose
(2) searchable by grep, replacable by sed, easily
(3) can follow to change DB engine's spec

I think it stands to reason all of (1)(2)(3).


But I'll use addslashes() instead of mysql_real_escape_string() because I know the escaping rule of addslashes() exactly.

It will be much better to use accustomed tools than unaccustomed tools.

eg) I've just found a SQL Injection in a famous script because of developper's ignorance which ` can't be escaped by addslashes()/mysql_real_escape_string().

Printer friendly page Send this story to a friend

Comments list

GIJOE  Posted on 2006/5/26 5:15 | Last modified
Quote:
SQL文に対するリテラルのエスケープに関しては、セキュリティとかINJECTIONなんて概念が一般的になる前でも、プログラマに対して「正しくプログラムを動作させる為に必要」って教育がされますから。

それはおっしゃる通りで、SQLの基本中の基本ですよね。
SQL Injection対策の「サニタイズ」でないことは明らかです。

このあたり、ちゃんと書いたつもりだったのに、読み返した「サイバーテロ本」では、そういう記述がどこにもなかったのには自分でも愕然としました。
確かに高木浩光氏に突っ込まれても仕方ないでしょう。

ただ、SQL Injectionとなる理由って2つありますよね。

・リテラルのエスケープし忘れ
・リテラルではない要素をSQLへ導入する

この後者のミスの方がむしろ怖いんじゃないかと思うんです。
後者の手抜きパターンとして、ORDER BY のカラム名を直指定して、ホワイトリストチェックなんてのがありますが、それは「サニタイズ」と言えなくもないでしょう。

…って全然違う話題で恐縮ですが。


いずれにせよ、PHP史的に、addslashes()の元々の用途が違うのだから、SQL用エスケープに利用すべきではない、という意見は傾聴する価値がありますね。


Quote:
余談ですが、PHPに関しては、簡易WEB作成ツールって位置付けで発祥した為かmagic_quote_gpcなんてのが最初から用意されていたがために、余計に混乱をもたらしているような気がします。これがために、少し前にはmagic_quote_gpc環境で無い場合にすべてのGPCに addslashesなんて処理が行われていた物もあったりします。
なるほど〜。
PHPはスタート地点からまともなプログラミング言語とは違うんですね。
magic_quotes_gpcも regiter_globals と同じく、過去の遺物なんでしょうね。
nobunobu  Posted on 2006/5/25 7:56
Quote:
`(バッククオート)も'(シングルクオーテーション)と同様にエスケープされる、なんて勘違いがベースにあったように思えます。
そもそも、addslashesの用途がINJECTION対策なんて意識が薄かった(無かった?)のだと思いますよ。
単純にSQL文中のリテラルの中に、クォーテーション文字が使われる可能性があるから、SQLエラーおこさないためには、エスケープの必然があって、
昔のMySQLの識別子で許されている文字が「英数字」と‘_’ と ‘$’ に限定されていたのでエスケープの必然が無いって意識がベースにあったのだと思います。
SQL文に対するリテラルのエスケープに関しては、セキュリティとかINJECTIONなんて概念が一般的になる前でも、プログラマに対して「正しくプログラムを動作させる為に必要」って教育がされますから。

余談ですが、PHPに関しては、簡易WEB作成ツールって位置付けで発祥した為かmagic_quote_gpcなんてのが最初から用意されていたがために、余計に混乱をもたらしているような気がします。これがために、少し前にはmagic_quote_gpc環境で無い場合にすべてのGPCにaddslashesなんて処理が行われていた物もあったりします。
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!