回答編集履歴
1
修正
answer
CHANGED
@@ -16,8 +16,12 @@
|
|
16
16
|
|
17
17
|
ストアドプロシージャもSQLインジェクション対策に効果的という意見があるようですが、安全性の低い動的SQLを利用することができるため唯一の解決策にはならないようです。結局正しく使わなければアプリーケーションで動的にSQLを使用するのと同じくらい危険らしいです。また、ストアドプロシージャを利用すればSQLのパフォーマンスの向上が上がると思いきや、アプリケーションサーバでできることはロードバランス可能なアプリケーションサーバで行った方がパフォーマンスの向上が図れるという意見がありました。
|
18
18
|
|
19
|
-
データアクセスフレームワークやオブジェクトリレーショナルマッピング(ORM)によってSQLインジェクションのリスクからコードを保護できるという意見があるそうです。しかし、これはSQLステートメントを文字列として直接記述できるフレームワークは当てはま
|
19
|
+
データアクセスフレームワークやオブジェクトリレーショナルマッピング(ORM)によってSQLインジェクションのリスクからコードを保護できるという意見があるそうです。しかし、これはSQLステートメントを文字列として直接記述できるフレームワークは当てはまらないようです。SQLステートメントを直接記述できないフレームワークの場合には、プリペアドステートメント同様の対策になり得る上、プリペアドステートメントでは不可能だった柔軟なSQL構築が可能となりますが、フレームワークの学習コストが発生するほか、SQLをコードから分離するということができなくなります。私はこのようなライブラリを利用してDBとやりとりした経験が少ないのですが、ActiveRecordを利用した時に地獄を見た経験があるため、ORMの利用は避けますがmaisumakunさんに紹介させていただいた[knex.js](http://knexjs.org)については初めて知りましたのでもう少し調べて見たいと思っています。
|
20
20
|
|
21
21
|
ユーザが入力したデータをバリデーションすることにより、ユーザからの入力に危険な文字列が含まれていないかどうかを探るよりも、その入力にとって無効な文字列を初めから全て取り除くようにするという考え方もありました。不正な値がデータベースに記憶されてしまうと、それだけでアプリケーションサーバが予期せぬ不具合を起こしたりすることが想定できるため、バリデーションをより厳密に行うことでSQLインジェクション対策になるというものです。これは安全かつ安定したアプリケーションの構築につながるため、SQLインジェクション対策とはまた別に意識しなければいけませんね。
|
22
22
|
|
23
|
-
結論として私はプリペアドステートメントを利用し、パラメータにできない部分についてはユーザの入力値を直接利用しないよう厳重注意し、どうしてもユーザの入力値を利用しなければならない場面については想定されない値の侵入をフィルタリングすることで対策することにしました。
|
23
|
+
結論として私はプリペアドステートメントを利用し、パラメータにできない部分についてはユーザの入力値を直接利用しないよう厳重注意し、どうしてもユーザの入力値を利用しなければならない場面については想定されない値の侵入をフィルタリングすることで対策するのがいいのではないかと考えています。柔軟なSQL文を生成するにはSQLをコードから分離することは難しいと思われますが、学習コストが低い上に文字列結合による値代入などを行わなければ安全性も高い上、調査した中では最も有効な対策方法(SurferOnWwwさんが前もって教えてくださっていましたが)と言われていたためです。
|
24
|
+
|
25
|
+
もう少しデータアクセスフレームワークについて調査するつもりですが、ひとまずわかったことをここにまとめ、解決とさせていただきます。
|
26
|
+
|
27
|
+
何か指摘箇所がありましたらぜひ教えていただけると嬉しいです。
|