回答編集履歴

2

追記&訂正

2020/09/03 00:42

投稿

退会済みユーザー
test CHANGED
@@ -8,7 +8,7 @@
8
8
 
9
9
 
10
10
 
11
- 対策以前に、質問に書かれた「知ったうえで対策を考えて書いたコード」の「例 1」は動かないと思いますが、それはちょっと置いといて、SQL 文のパラメータ化の観点だけから対策前後のコードを見ると、
11
+ 対策以前に、質問に書かれた「知ったうえで対策を考えて書いたコード」の「例 1」は動かないと思いますが、それはちょっと置いといて(=「例 1」は議論の対象外とし「例 2」だけ考えてという意味)、SQL 文のパラメータ化の観点だけから対策前後のコードを見ると、
12
12
 
13
13
 
14
14
 
@@ -28,7 +28,7 @@
28
28
 
29
29
 
30
30
 
31
- ・・・となっていて、パラメータ化による SQL インジェクション防止対策は考えれていると思います。
31
+ ・・・となっていて、パラメータ化による SQL インジェクション防止対策は考えれていると思います。
32
32
 
33
33
 
34
34
 

1

訂正

2020/09/03 00:42

投稿

退会済みユーザー
test CHANGED
@@ -32,7 +32,7 @@
32
32
 
33
33
 
34
34
 
35
- ただ、決意をもった攻撃者はパラメータ化さ突破できるそうで(Microsoft のドキュメントに書いてあったこと。そのドキュメントは見つかりませんが)、以下の記事の「すべての入力の検証」セクションに書いてあるように "型、長さ、形式、および範囲をテストすることによってユーザー入力を必ず検証してください" も対処する必要があると思います。
35
+ ただ、「高いスキルを持つ攻撃者はパラメータ化されたデータであって操作できるそうで(下に紹介した Microsoft のドキュメントに書いてあったこと)、以下の記事の「すべての入力の検証」セクションに書いてあるように "型、長さ、形式、および範囲をテストすることによってユーザー入力を必ず検証してください" も対処する必要があると思います。
36
36
 
37
37
 
38
38