私信
ゆーすけべー社長、2周年おめでとうございます♪
ワディット2周年にあたって feat. ESPer2008講演 「いつのまにか社長になっていた」
セキュアなコードを目指して
＜title＞をクールにしてみた！で公開したコードの件。ちょっと混乱してるのでいったん整理する。
安易にextract($_GET); を使うとどうなるかというのは、言及してくださった方が
分かりやすい例を用いて解説してくれたので、そちらを直接見てくれた方が良いと思う。
なぜ入力値に extract を使用すると危険なのか の部分 - まちゅダイアリー
すでに誰かが突っ込んでいるが、extract($_GET); はまずい。 の部分 - Web屋のネタ帳
文字コード指定は mysql_set_charset を使うべし
× mysql_query("set names utf8");
○ mysql_set_charset("utf8");
mysql_set_charset - PHP Manual
この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは
使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。
SET NAMESは禁止 - yohgaki's blog
#いま気付いたがコメント欄で議論が！
関連でちょっと気になるエントリもあったが・・・
SET NAMESは禁止？ - CakePHP のおいしい食べ方
prepared statementを使うべし
プリペアドステートメントってなんだ！
mysql-ja: Prepared Statement (訳） - MySQL Lists
”アドホックなクエリのストリング”というあたりで危うく引き返しそうになった。
私は、日常的に使用しないカタカナ語が3つ続くとバグる。要・成長。
泣きながら「ていうか腹減った！」と生姜焼き弁当を買いに走ったことはさておき、
ピコーンと来た部分を上記記事より一部引用。
Prepared statementはSQL のロジックとデータを分離することで
セキュリティを増加します。ロジックとデータを分離することで、
SQLインジェクション攻撃を回避することができます。
通常のクエリを扱っている場合、ユーザから受け取ったデータを
処理するには注意が必要です。
これはシングル・クオート、ダブル・クオート、バックスラッシュなどの
文字をエスケープする関数を使用することに関係します。
こういったことはprepared statementを使用する際には不必要です。
どうやら私が使いまくっていたMySQL関数は古いらしく、prepared statementの実装が無いという。
よく考えたらそうか。言語も人も世界も進化しているのだから、数年前の参考書に頼るのはイクナイ。
Web屋のネタ帳さんのサンプルコードを見た際、
「$himituという変数の存在に気づかれる可能性は低いから大丈夫だっぺ！」
と思ったら光速でイエローカード出されたｗｗｗ
そうか・・・どこで尻尾を出しちゃうか分からないしなあ・・・・。
安全性確保のため mysql_real_escape_string を使うべし
以前、SQLインジェクションについて書いた際、下記TBをいただいた。
mysql_query関数は複合クエリに対応していない為、
SQL文中にセミコロンが入っている時点でエラーになります。
re:キケンなSQLインジェクション - to-R
すっかりセフセフな気分でいたが、それ以外にも方法があるからやっぱりダメらしい＞＜
そこで mysql_real_escape_string。
SQL 文中で用いる文字列の特殊文字をエスケープし、
mysql_query() で安全に利用できる形式に変換します。
データの安全性を確保するため、MySQL へクエリを送信する場合には
（わずかな例外を除いて）常にこの関数を用いなければなりません。
mysql_real_escape_string - PHP Manual
以上を踏まえて書き直す。うーっ。レディー・GO！！
べにぢょが頑張りますように！（phaさんのついったー発言の真似）
