質問編集履歴
1
具体的に変更
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
Railsの
|
|
1
|
+
Railsのprotect_from_forgeryで生成されるauthenticity_tokenの信ぴょう性
|
test
CHANGED
|
@@ -1,13 +1,35 @@
|
|
|
1
|
-
RailsでCSRF
|
|
1
|
+
ひょんなことからRailsのアプリを触る機会があり、Railsデフォルトで用意されているCSRF対策について調査しています。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Railsではデフォルトで`application_controller`内に`protect_from_forgery with: :exception`の記述があります。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
authenticity_token
|
|
9
|
+
これにより、POST、PUTの際にヘルパーが自動的に`authenticity_token`を生成（もしくはヘッダーに付与）し、セッション変数と照らし合わせることによりCSRFの対策をしているようです。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
+
しかしながら、実際の挙動を確認したところ、
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
**一度生成された`authenticity_token`は使いまわしが可能**
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
という挙動になっていました。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
`authenticity_token`は通常にサイト内回遊すると、毎回別のトークンが生成されますが、「必ずしもそこで生成されたトークンである必要はない」ということです。（前ページで生成されたトークンも使用可能）
|
|
26
|
+
|
|
27
|
+
※もちろん別セッションとなった場合の使い回しは不可能
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
これってCSRF対策として十分なんでしょうか？仮に`authenticity_token`の値を知り得てしまった場合、セッションが消えるまではそのトークンを用いることでリクエスト自体は通ってしまうため、ちょっと微妙なのでは、、、？と思ってます。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
13
|
-
この辺りの挙動に
|
|
35
|
+
この辺りの挙動/あるべき姿に詳しい方からのご教示をお待ちしています。
|