第6回 意外に知られていないブラインドSQLインジェクション | gihyo.jp
前回の記事でSQLインジェクションの話は終わりにして、クロスサイトスクリプティングの話を書かせて頂こうと思っていました。しかし、6月5日に東京にて開催されたPostgreSQLカンファレンス2007でセキュリティをテーマに講演させて頂き、意外にブラインドSQLインジェクションをご存じでない方が沢山いらっしゃいました。40名ほどの聴講者の皆様にSQLインジェクションをご存じの方？とお聞きするとほぼ全ての方が知っていると答えたのですが、ブラインドSQLインジェクションをご存じの方は数名でした。 SQLインジェクションの常識 ブラインドSQLインジェクションの話をする前に、SQLインジェクションとその対策の常識について確認します。 SQLインジェクション対策として間違ってはいないが不十分な対策 エラーメッセージを表示しない（特にSQLエラー） ユーザ入力文字列をエスケープする これらはSQLイン
書式文字列によるSQLインジェクション攻撃例
以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは？ と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ？と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
