忍者ブログ
やったことの記録 主にlinuxとかperlとか
プロフィール
HN:
隠居SE
性別:
非公開
カテゴリー
P R
ブログ内検索
忍者カウンター
[23] [22] [21] [19] [18] [17] [16] [15] [14]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

ネットを徘徊していて、
未だSQLインジェクション対策について誤解されている方が多いのかな?と感じることがあったので、
ここに正しいSQLインジェクション対策とはどう言うものかを簡単に記載しておきます。


そのために、まずSQLインジェクションとは何かをかいつまんで説明します。

SQLインジェクションとは、SQL文に差し込まれたデータによってSQL文が改変され、
意図しない結果を返してしまうことを言います。

$id = "1234";
$pass = "' or pass != '";
select * from account_table where id = '$id' and pass = '$pass';
select * from account_table where id = '1234' and pass = '' or pass != '';



そしてその原因は、外部から入力されたデータ(入力データ由来の保存データも含む)を用いて動的にSQL文を組み立てることにあります。
(上記はデータの差し込みですが、order by句などでカラム名を差し込む場合も同じです)


ですから、正しいSQLインジェクション対策とは、
動的にSQL文を生成しないことになります。

そして、静的SQL文のみでアプリケーションを組み立てるには、
プレースホルダを使わなければならないと言うことです。


ですから、プレースホルダを使っていても、
外部から入力されたデータがSQL文に混入するような動的SQL文の構築を行っていたのでは、
全く意味はありません。


ソート順をユーザーに選択させるようなシーンは滅多にないでしょうし、
必要な場合でも結果をすべて読み込むようなケースであれば、
アプリ側でソートすれば済む話です。
(私は、ソートのような単純処理は、DBサーバー側ではなくAPサーバー側で行う派です。
 理由は、Apサーバーの方がスケールアウトが容易だからです)

もちろん、読み込むカラムも、絞り込み条件も、ソート順もユーザーが任意に指定できるようにするような、
DB管理ソフトのようなものでは動的SQLの構築は避けられませんが、
そのようなアプリケーションを組む人がいったいどれだけ居ると言うのでしょうか?
(そのような場合でも、enumを利用するなど、入力データを用いないようにすることはできますが)

そのようなレアケースを軸とした対策ではなく、
プログラマのスキルによらず確実に対応できるようにすることこそが、
正しい対策です。


動的SQLの生成は止めましょう。
プログラムの先頭でprepareしておいても正しく動くプログラムを目指しましょう。

PR
この記事にコメントする
お名前:
タイトル:
文字色:
メールアドレス:
URL:
コメント:
パスワード:   Vodafone絵文字 i-mode絵文字 Ezweb絵文字
Powerd by NINJAブログ / Designed by SUSH
Copyright © 隠居SEの備忘録 All Rights Reserved.
忍者ブログ/[PR]