Open Source Web Development Tutorials - Dev Shed

MySQL＆PHPアプリからSQLインジェクションを防ぐ
（2009/03/26公開）

読者からのコメント

MySQL＆PHPアプリからSQLインジェクションを防ぐへの返信
匿名希望
2009年1月9日：PM1時25分

　この記事は、削除するか修正するべきだ。間違ったアドバイスがあるし、人々を危険にさらすよ。

　僕のコメントはここまで。

------

MySQL＆PHPアプリからSQLインジェクションを防ぐへの返信への返信
匿名希望
2009年1月7日：PM9時36分

　やぁ。

　もちろん、全部のスクリプトがパーフェクトなわけじゃないさ。直すべきところもある。この記事のどの部分に対して、君は欠陥がある、あるいは適切じゃないと思っているのか、僕たちにも教えてくれないかな。僕たちはそれを判断するし、読者も考えたり改めたりできるだろ。

　ありがとう。

------

なせこのコードが危険なのか？
匿名希望
2009年1月8日：AM5時49分

　最初の匿名希望さんが、この記事のコードがどうして危険なのかをもっとちゃんと説明するっていうのは、いい考えだと思う。

　おれみたいな、初心者で無知なやつらには、何でこのコードが悪いのか分からないんだ。

　それに、読者を迷わせるような記事ならば、DevShedはこんな記事を載せるべきじゃないってことになるだろ。

　最初の匿名希望さんが別の何かを意図しているんじゃなければね。

間違い
匿名希望
2009年1月7日：PM6時10分

　mysql_real_escape_string()は、いつ使われるべきか。常に。以上、終わり。それ以外を答えるやつは、だまされてるね。

　まあ、能力あるハッカーがどうやってmysql_real_escape_string()をハックするのか、っていう説明を聞くのは好きなんだけどね。

　普段使われている表現の入力データ全部が、ブラックリストキャラクターにあたるか、検証するだって。間違いだね。2009年なら、フィルター拡張で使われる表現を検証すればいい。最新情報についてこいよ、一番よいセキュリティーのプラクティスを勉強しろよ。じゃなければ、記事なんて書くな。

有益な情報はここにはない
匿名希望
2009年1月7日：PM8時54分

　Devshedには、もっと基本を期待していた。

　使えるもんなんてなんにもないさ。

この記事にだって多少の価値はある
匿名希望
2009年1月7日：PM9時31分

　著者はさ、SQLインジェクション攻撃の危険性に焦点をあてているんだけど、ここには本当に役立つものがほんの少しだけあるよ。初心者のPHPスクリプトがこうしたソートの問題を避けるっていうね。

　PHPとSQLインジェクション関連の記事は、mysql_real_escape_string()にがっちり焦点をあてるべきだ。要するに、あれだ、バックスラッシュを使って、\x00、\n、\r、\、'、"、\x1a.をエスケープするってやつだ。これは、SQLインジェクションの防止の基本だけどさ、この著者はこれを補足みたいにしてる。

　すごくよい記事であるならば、php/mysqlスクリプトを書く場合のベストプラクティスをいくつか提供するね。僕のスクリプトはいつも、下に紹介するテクニックを使っている。これはphp.netサイトの、mysql_real_escape_string()のところから引っ張ってきたものだよ。

1．まず、magic quotes gpcがオンかどうかをチェックする。そうなら、それぞれの$_POST 変数でstripslashes()を走らせる。

2．以下のような形で、sprintfを使って、mysql_real_escape_string()で走らせる変数と一緒にクエリーを構築する。
$sql=sprintf("SELECT * FROM tablename WHERE columnname='%s' AND columnname2='%s'",
mysql_real_escape_string($var1),mysql_real_escape_string($var2));

頼む、この記事を削除して！
匿名希望
2009年1月8日：AM2時45分

　SQLインジェクションに関するアドバイスの中で、考え得る限りで最悪のものが、この記事だね。1つ、文字配列のエスケープをベースにして、regexを扱うって言うのは、長い失敗の歴史があるんだ。これは有効な入力を拒否して、思いつかないような無効な入力を受け入れてしまいかねない。2つ目、可能な一番後のタイミング（例えばクエリータイムなど）で、入力のエスケープをするべきだ。全部の入力がきれいにされたことを検証できるから。3つ目、数字の例は、記事の内容で言われているような動作をしない。'123-abcd'とあるのは>.0001が正しい。

------

Joey P.
匿名希望
at: 01-23-09 @ 8:38 pm EST

　変数は「>.0001」っていうのが、まったくひどいアドバイスだってことをチェックしてみな。つまり、上のは「12'; delete * from user where 1;」でやれば、通るよ。
Typecastingが解決してくれるよ。下のコマンドを試してみて。

$var=(int)$var.

MySQL＆PHPアプリからSQLインジェクションを防ぐへの返信
匿名希望
2009年1月8日：AM3時23分

　アマチュアとプロの違いは、検証の違いだね。

私見
匿名希望
2009年1月28日：PM3時17分

・「セキュリティーの専門家」なら、SQLのストアドプロシージャーだけを使うことをお勧めする。あたかもStarship Enterpriseのフォースフィールドであるかのように。クラッカーもこれを使う。しかし、これを使うことはいつも好ましい。

・Javascriptの検証はいいことだ。Javascriptを有効にしない数百万のユーザー全部に対応する必要があるというようなことを言う人たちのことはさておいてもだ。ああ、もしJavascriptを無効にしているなら、インターネットの半分、つまりgoogle、Yahoo、マイクロソフト、広告が使えないだろう。やつらにけんかを売ってやれ。

・Javascriptに頼るな。

・Javascriptに夢中になるな。要するに、有効なデータが入力されるまで、ユーザーにひっついてるブタになるな。

・ユーザーがJavascriptを有効にしているかどうかは、かれらを自分のサイトに入れる前にチェックしろ。とにかく丁寧に、それが必要なことを知らせろ。一度サイトに入ったらJavascriptをオフにして監獄破りを試みられる場合に備えて、各ページでもチェックすること。

・できるだけたくさんJavascriptのチェックを行うことは、PHPの基本だ。大して難しいことじゃない。

・PHPにおける、明らかなSQLインジェクションやスクリプトの入力に気付き対応するべし。明らか、あるいはそれほど明らかではない作り話があれば（リクエストは投稿ではない、など）、PHPループのトライアングルにやつらを放り込むのがいいね。

・PHPを信頼するな。データベース設計に制約を加えろ。

・ソースを隠せ、サイトを覆い隠せ。

・できる限り全部のJavascriptを客観化せよ。

・HTTPリファラーをチェックせよ、しかし信頼するな。

・スクリプトパスをチェックせよ、単に地獄のために。

・セッションクッキーのみを使え。そうでなければ。httpだけにクッキーを設定しろ。たとえこれがバカにでもできるようなものでないにしても。

・mysql_escapeは、phpへの全httpインプットに対応する。

・プラス$10を支払え、そうでなければURL全体にSSLを使え。心配しなくてもいいような情報があれば。それらは別のサブドメインに置いておけ。

　もっとたくさんある、OWASP/NIST/SANSのサイト（初期化されていない／不明確な変数がないこと、二重のcookieがないことなどなど）をチェックしてほしい。

　誰もがセキュリティーの道は通る（疑いは喜ばしくないが、確信はばかげている－ヴォルテール）。君のアプリケーションが「完全にセキュア」なら、誰も近づけないし、その存在を誰も知り得ない。論理はばかげている。

　誰かが（銀行、政府）、自分たちのアプリケーションやデータは「完全にセキュア」だと言い張るなら、そいつらは大バカで、無知で、妄想屋で、うそつきだ。

　最後に伝えるのは、ちょっと古くさい言葉だ。銃でもバットでもなんでも持て。そしてハッカーを見つけたら、砂漠の中に埋めてしまえ。