回答編集履歴
6
追記
test
CHANGED
|
@@ -33,6 +33,18 @@
|
|
|
33
33
|
というのが正しい事でしょう。
|
|
34
34
|
|
|
35
35
|
|
|
36
|
+
|
|
37
|
+
加えて、
|
|
38
|
+
|
|
39
|
+
1. 決済を行うにはログインを必須にする
|
|
40
|
+
|
|
41
|
+
2. ログインユーザーを作成する際にSMSやIVR等の認証を挟んで無制限なユーザー作成を防ぐ
|
|
42
|
+
|
|
43
|
+
3. 怪しい行動が検知されたらユーザー単位でアクセス制限を行う
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
と言う様な処理で対応可能なケースになってしまいますね。
|
|
36
48
|
|
|
37
49
|
|
|
38
50
|
|
5
補足
test
CHANGED
|
@@ -24,9 +24,13 @@
|
|
|
24
24
|
|
|
25
25
|
その場合は
|
|
26
26
|
|
|
27
|
-
クレジットカード情報の正当性を確認するのはサイト側の責任範囲では無いので、
|
|
27
|
+
クレジットカード情報の正当性を確認するのはサイト側の責任範囲では無いので、
|
|
28
28
|
|
|
29
|
+
改正割賦販売法とクレジットカード決済代行プラットフォームの求めるサイト仕様を満たしたうえで、
|
|
30
|
+
|
|
31
|
+
カード情報の正当性自体はクレジットカード決済代行プラットフォーム側で対処させる。
|
|
32
|
+
|
|
29
|
-
というのが正しいでしょう。
|
|
33
|
+
というのが正しい事でしょう。
|
|
30
34
|
|
|
31
35
|
|
|
32
36
|
|
4
追記
test
CHANGED
|
@@ -24,19 +24,11 @@
|
|
|
24
24
|
|
|
25
25
|
その場合は
|
|
26
26
|
|
|
27
|
+
クレジットカード情報の正当性を確認するのはサイト側の責任範囲では無いので、クレジットカード決済代行プラットフォームの求めるサイト仕様を満たしたうえで、クレジットカード決済代行プラットフォーム側で対処させる。
|
|
28
|
+
|
|
29
|
+
というのが正しいでしょう。
|
|
27
30
|
|
|
28
31
|
|
|
29
|
-
1. ログインしないと決済試行出来なくする
|
|
30
|
-
|
|
31
|
-
2. ユーザー作成において、SMSやIVRによる認証等を併用することで、大量の捨てアカウントを作れなくする
|
|
32
|
-
|
|
33
|
-
3. 問題があった場合（複数回連続で決済に失敗した場合）はログイン情報でアクセス制限を行う
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
という方法で問題無く対応出来る事でしょう。
|
|
38
|
-
|
|
39
|
-
＊きちんとカード決済の処理を行っていれば、決済代行プラットフォーム側で検知/ブロックしてくれる可能性も高いとは思いますが。
|
|
40
32
|
|
|
41
33
|
|
|
42
34
|
|
3
追記
test
CHANGED
|
@@ -20,17 +20,23 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
+
|
|
24
|
+
|
|
23
25
|
その場合は
|
|
26
|
+
|
|
27
|
+
|
|
24
28
|
|
|
25
29
|
1. ログインしないと決済試行出来なくする
|
|
26
30
|
|
|
27
31
|
2. ユーザー作成において、SMSやIVRによる認証等を併用することで、大量の捨てアカウントを作れなくする
|
|
28
32
|
|
|
29
|
-
3. 問題があった場合はログイン情報でアクセス制限を行う
|
|
33
|
+
3. 問題があった場合（複数回連続で決済に失敗した場合）はログイン情報でアクセス制限を行う
|
|
30
34
|
|
|
31
35
|
|
|
32
36
|
|
|
33
37
|
という方法で問題無く対応出来る事でしょう。
|
|
38
|
+
|
|
39
|
+
＊きちんとカード決済の処理を行っていれば、決済代行プラットフォーム側で検知/ブロックしてくれる可能性も高いとは思いますが。
|
|
34
40
|
|
|
35
41
|
|
|
36
42
|
|
2
追記
test
CHANGED
|
@@ -1,3 +1,41 @@
|
|
|
1
|
+
質問の追記を受けての追記
|
|
2
|
+
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
> 例えば、クレジットカードを拾ったため、それを悪用して決済を何度も試行する等を
|
|
8
|
+
|
|
9
|
+
> イメージしていただければと思います。
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
この想定だと、
|
|
14
|
+
|
|
15
|
+
ログインさせずに非所有のクレジットカードの決済試行という犯罪を試行出来るということになってしまうので、
|
|
16
|
+
|
|
17
|
+
「1ユーザーがちょっとした悪さ程度の悪行を働いた場合を想定していただければと思います。」の範疇から大きく外れるように思いますよ。
|
|
18
|
+
|
|
19
|
+
（単純な表現の問題だとは思いますが、「ちょっとした悪さ」としては外れすぎている様に思います）
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
その場合は
|
|
24
|
+
|
|
25
|
+
1. ログインしないと決済試行出来なくする
|
|
26
|
+
|
|
27
|
+
2. ユーザー作成において、SMSやIVRによる認証等を併用することで、大量の捨てアカウントを作れなくする
|
|
28
|
+
|
|
29
|
+
3. 問題があった場合はログイン情報でアクセス制限を行う
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
という方法で問題無く対応出来る事でしょう。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
1
39
|
既に回答のある通り、本気のアタックに対して完全に解決することは不可能です。
|
|
2
40
|
|
|
3
41
|
|
1
副作用の追記
test
CHANGED
|
@@ -70,6 +70,22 @@
|
|
|
70
70
|
|
|
71
71
|
|
|
72
72
|
|
|
73
|
+
**副作用について追記**
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
maisumakunさんのコメントを受けての追記
|
|
78
|
+
|
|
79
|
+
> これの副作用として、「巻き添えブロックを発生させるための荒らしが出現する」例もあるようです。
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
巻き添えが大きくなりすぎると攻撃者の思う壺でもあるので、
|
|
84
|
+
|
|
85
|
+
短期的なブロックに留める等の工夫と、巻き添えにされた人に対するケアをどうするかという部分を考える必要が出てきますね。
|
|
86
|
+
|
|
87
|
+
中々難しそうです。
|
|
88
|
+
|
|
73
89
|
|
|
74
90
|
|
|
75
91
|
法的な手段に訴える
|