回答編集履歴
1
修正
test
CHANGED
|
@@ -34,7 +34,7 @@
|
|
|
34
34
|
|
|
35
35
|
|
|
36
36
|
|
|
37
|
-
データアクセスフレームワークやオブジェクトリレーショナルマッピング（ORM）によってSQLインジェクションのリスクからコードを保護できるという意見があるそうです。しかし、これはSQLステートメントを文字列として直接記述できるフレームワークは当てはま
|
|
37
|
+
データアクセスフレームワークやオブジェクトリレーショナルマッピング（ORM）によってSQLインジェクションのリスクからコードを保護できるという意見があるそうです。しかし、これはSQLステートメントを文字列として直接記述できるフレームワークは当てはまらないようです。SQLステートメントを直接記述できないフレームワークの場合には、プリペアドステートメント同様の対策になり得る上、プリペアドステートメントでは不可能だった柔軟なSQL構築が可能となりますが、フレームワークの学習コストが発生するほか、SQLをコードから分離するということができなくなります。私はこのようなライブラリを利用してDBとやりとりした経験が少ないのですが、ActiveRecordを利用した時に地獄を見た経験があるため、ORMの利用は避けますがmaisumakunさんに紹介させていただいた[knex.js](http://knexjs.org)については初めて知りましたのでもう少し調べて見たいと思っています。
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
@@ -42,4 +42,12 @@
|
|
|
42
42
|
|
|
43
43
|
|
|
44
44
|
|
|
45
|
-
結論として私はプリペアドステートメントを利用し、パラメータにできない部分についてはユーザの入力値を直接利用しないよう厳重注意し、どうしてもユーザの入力値を利用しなければならない場面については想定されない値の侵入をフィルタリングすることで対策することにしました。
|
|
45
|
+
結論として私はプリペアドステートメントを利用し、パラメータにできない部分についてはユーザの入力値を直接利用しないよう厳重注意し、どうしてもユーザの入力値を利用しなければならない場面については想定されない値の侵入をフィルタリングすることで対策するのがいいのではないかと考えています。柔軟なSQL文を生成するにはSQLをコードから分離することは難しいと思われますが、学習コストが低い上に文字列結合による値代入などを行わなければ安全性も高い上、調査した中では最も有効な対策方法（SurferOnWwwさんが前もって教えてくださっていましたが）と言われていたためです。
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
もう少しデータアクセスフレームワークについて調査するつもりですが、ひとまずわかったことをここにまとめ、解決とさせていただきます。
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
何か指摘箇所がありましたらぜひ教えていただけると嬉しいです。
|