PREPARE と EXECUTE を使っても SQLインジェクションできませんか？

SQLインジェクション対策について勉強しだしました。
そこで疑問が浮かんだのですが、

SQL
1PREPARE login_statement (text, text) AS
2SELECT * FROM users WHERE id = $1 AND pass = $2;

でステートメントを用意したとして。

SQL
1EXECUTE login_statement($id , $pass);

で呼び出す際に、

$id = , ''); INSERT INTO users VALUES ('hogeid
$pass = hogepass

を渡された場合、

SQL
1EXECUTE login_statement('', ''); INSERT INTO users VALUES ('hogeid', 'hogepass')

こうなると思いますが
このINSERTは実行されますか？

miyahan

2017/07/08 10:25

なぜ実際にご自身でやってみないのですか？

退会済みユーザー

2017/07/08 10:30

実際にサイトを作らないといけないからです。

miyahan

2017/07/08 10:33

ここは作る人向け質問サイトですよ

退会済みユーザー

2017/07/08 11:04

作ろうと思えば作れると思いますが、今は大学の課題が溜まっていて時間が取れないです。質問に答えていただけませんか。ｍ（＿　＿）ｍ

行動規範の内容に同意します

回答3件

ベストアンサー

他の方も書いてますが、問題ありません。
プリペアドステートメントはDB側の仕組みでアプリケーションプログラムで文字列連結を行うものとは異なります。
一般的なDB製品では「置換する前のSQL」と「パラメータ」が別々に送信され、パラメータの適用はDB側で行います。
荒っぽくいってしまえばDBはSQL本体とパラメータとの区別がSQL発行時にわかっているので良きに解釈してくれるということです。
余談ですが、プリペアドステートメントをつかうと
①「置換前のSQLの解析->パラメータの適用」
とDB側で処理が行われるのに対し、使わないと
②「パラメータ置換後のSQLの解析」
のみが行われます。
いずれもSQLの解析結果をDB側でキャッシュしますが、①はパラメータが違う場合でも同じキャッシュが利用できるのに対し、②はパラメータが異なればキャッシュが異なります。なのでキャッシュのヒット率は①が断然いいケースがほとんどです。なのでセキュリティ的にも性能的にもプリペアドステートメントは有利。
さらに余談ですが、プリペアドステートメントつかっても少し自力エスケープを意識しなきゃならないケースもあります。そのひとつはlike検索などワイルドカード使う場合でしょうか。
例えば"%"を検索パラメータとして与えた場合、これがが検索対象なのか、ワイルドカードなのかDB側ではわからないためです。
※結構この対策漏れてることが多いので%で検索->検索件数大量ヒットさせてDoSアタック仕掛けるという手口も考えられるので一応。