回答編集履歴
1
追記
test
CHANGED
|
@@ -25,3 +25,43 @@
|
|
|
25
25
|
なお、いわゆる`ID`を`UUID`化すべきかはケースバイケースでしょう。
|
|
26
26
|
|
|
27
27
|
たとえば`ユーザーID`などはそうすべきでしょうが、`都道府県ID`のような推測されても問題ないものはその必要はないでしょう。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
## 追記
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
同じような質問が見つかったので提示しておきます。
|
|
36
|
+
|
|
37
|
+
[Django 2.x: Is using the Primary Key of a Model in the URL pattern a security concern?](https://stackoverflow.com/questions/57478609/django-2-x-is-using-the-primary-key-of-a-model-in-the-url-pattern-a-security-co)
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
おおむね、IDが連番であることによるセキュリティ上の懸念は考えられるが
|
|
42
|
+
|
|
43
|
+
そもそもそのIDが指すモノに対する取得、閲覧、変更などの認可制御を適切に処理する仕組みがあるのでそれを使うべき。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
といった回答がついています。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
また[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity.html)の`1.11 アクセス制御や認可制御の欠落`にも同様な記載がされていました。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
> これも、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための注
|
|
56
|
+
|
|
57
|
+
文番号が、ログイン中の利用者に閲覧を許可された番号であるかどうかを常に確認するように実装し
|
|
58
|
+
|
|
59
|
+
てください。
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
UUID化のメリットとしては「他のIDの推測を回避できる」点くらいです。
|
|
64
|
+
|
|
65
|
+
よってコピーサイトの作成などを目的としたデータの**一括取得**対策にはなるでしょう。
|
|
66
|
+
|
|
67
|
+
ただしIDの指すモノに対するセキュリティはシステムで用意された認可制御を用いるべきです。
|