数値項目に対するSQLインジェクション対策 - ockeghem's blog
文字列項目に対するSQLインジェクション対策は、「'」(シングルクォート)や「\」(円マーク、バックスラッシュ)のエスケープであるが、数値リテラルなどはエスケープでは対策できない。 ここで、なぜ文字列に対してエスケープ処理が対策になるかを復習しておこう。それは「どんな文字(列)に対しても正しいSQL文を生成する」ためである。一方、数値の場合は、どんな数値であってもエスケープ処理などは元々必要ない。それにも関わらずSQLインジェクション脆弱性が混入するのは、数値を想定した変数に数値以外の文字が混入するからに他ならない。 すなわち、文字列の場合と数値の場合は、対策の前提が異なるわけである。 ここで、高木浩光氏からの批判に戻ると、関連する内容は以下のとおりである。 「対策は入力値の妥当性検証」 < それは違う。SQL文構成時直前に型変換（ないし型検査）する。文字列のクオート同様 以下、いくつかの
数値リテラルをシングルクォートで囲むことの是非 - ockeghem's blog
高木浩光氏からの批判の一つは、数値リテラルをシングルクォートで囲むことに対する論拠のあいまいさであったように思う。 「性能的にも不利だし」 < 性能の影響は皆無。問題はそこではなく、挙動がSQL仕様で定義されているか。 以下にもう少し掘り下げて考察してみよう。 SQL仕様でどう定義されているか? 以下のようなSQLで、列IDがint型であると仮定しよう DELETE FROM DOCUMENTS WHERE ID=1 この数値リテラル1をシングルクォートで囲んだ場合の動作はどう規定されているか? DELETE FROM DOCUMENTS WHERE ID='1' 今手元にJIS SQLなどの規定がないので記憶に頼って書くしかないが、このような場合は、varchar型などの文字型から、int型への「暗黙の型変換」が実施される。つまり、'1'という文字列は、1という数値(整数)に変換されてか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
