回答編集履歴
4
コメントを受けてセッション開始の条件を訂正
test
CHANGED
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
(2/24 ご質問の1への回答を若干編集しました)
|
|
2
|
+
(2/25 コメントを受けてセッション開始の条件を訂正)
|
|
2
3
|
|
|
3
4
|
まず、参考資料を示します。
|
|
4
5
|
|
|
@@ -32,7 +33,7 @@
|
|
|
32
33
|
- 守りたい通信が開始するときにセッションを開始する。
|
|
33
34
|
- 守りたい通信が終了したら即座にセッションを破棄する。
|
|
34
35
|
|
|
35
|
-
今回の場合は、入力フォームに入った段階でセッションを開始し、完了時にセッションを破棄するようにします。
|
|
36
|
+
今回の場合は、入力フォームで最初に入力があった段階でセッションを開始し、送信完了 (または取り消し) 時にセッションを破棄するようにします。
|
|
36
37
|
|
|
37
38
|
なお、セッションの破棄のしかたについては末尾\[1]に補足します。また、今回はログインはしないとのことですが、する場合について\[2]に補足します。
|
|
38
39
|
|
3
ご質問の1への回答を若干編集しました
test
CHANGED
|
@@ -1,3 +1,5 @@
|
|
|
1
|
+
(2/24 ご質問の1への回答を若干編集しました)
|
|
2
|
+
|
|
1
3
|
まず、参考資料を示します。
|
|
2
4
|
|
|
3
5
|
- IPA セキュアプログラミング講座 (Webアプリケーション編)
|
|
@@ -24,6 +26,13 @@
|
|
|
24
26
|
session\_regenerate\_id()は、あまり必要ないと思います。
|
|
25
27
|
|
|
26
28
|
セッション開始時はsession\_start()だけでいいです。実装上は、IDを生成するたびにOSの(疑似)乱数生成器を使っているだけなので、あらためてsession\_regenerate\_id()しても暗号論的な強度は変わりません。
|
|
29
|
+
|
|
30
|
+
また、セッションの生成と破棄ですが、次の原則を守るべきです。
|
|
31
|
+
|
|
32
|
+
- 守りたい通信が開始するときにセッションを開始する。
|
|
33
|
+
- 守りたい通信が終了したら即座にセッションを破棄する。
|
|
34
|
+
|
|
35
|
+
今回の場合は、入力フォームに入った段階でセッションを開始し、完了時にセッションを破棄するようにします。
|
|
27
36
|
|
|
28
37
|
なお、セッションの破棄のしかたについては末尾\[1]に補足します。また、今回はログインはしないとのことですが、する場合について\[2]に補足します。
|
|
29
38
|
|
|
@@ -70,12 +79,7 @@
|
|
|
70
79
|
|
|
71
80
|
\[2] ログインする場合について補足します。
|
|
72
81
|
|
|
73
|
-
まず、セッションの生成と破棄ですが、次の原則を守るべきです。
|
|
74
|
-
|
|
75
|
-
- 守りたい通信が開始するときにセッションを開始する。
|
|
76
|
-
- 守りたい通信が終了したら即座にセッションを破棄する。
|
|
77
|
-
|
|
78
|
-
|
|
82
|
+
上で述べた原則により、基本的には**ログイン成功したときにsession\_start()し、ログアウトしたらすぐにsession\_destroy()する**ようにします。
|
|
79
83
|
|
|
80
84
|
なお、ログイン中以外でもセッションを使っているかもしれませんが、ログイン後に同じセッションを使いまわす (session\_regenerate\_id()でIDだけ変える) ように**しない**ほうがいいでしょう。ログインしていない間に攻撃者から情報を注入されたときに、それを信頼してログイン後にも使ってしまうようなコードを書けてしまいます。
|
|
81
85
|
|
2
微修正
test
CHANGED
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
|
|
40
40
|
複数回のリクエストがほぼ同時に発行されるため、その間にセッションIDが再生成されると、クライアントが最新のセッションIDを受け取り損ね、セッションが切れてしまう可能性があります。
|
|
41
41
|
|
|
42
|
-
ですので、ログインセッション中に**セッションIDを再生成する必要はない**と思います。次で述べるセッションクッキーのタイムアウトが設けられていればいいでしょう。
|
|
42
|
+
ですので、上で述べた対策がとられている限り、ログインセッション中に**セッションIDを再生成する必要はない**と思います。次で述べるセッションクッキーのタイムアウトが設けられていればいいでしょう。
|
|
43
43
|
|
|
44
44
|
> ２ セッションクッキーのタイムアウトについて
|
|
45
45
|
|
1
ログインする場合の説明を補足に移動。
test
CHANGED
|
@@ -21,18 +21,11 @@
|
|
|
21
21
|
|
|
22
22
|
> １ どのタイミングでセッションを再生成すればよいか。
|
|
23
23
|
|
|
24
|
-
session\_regenerate\_id()は、あまり必要ないと思います。
|
|
24
|
+
session\_regenerate\_id()は、あまり必要ないと思います。
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
セッション開始時はsession\_start()だけでいいです。実装上は、IDを生成するたびにOSの(疑似)乱数生成器を使っているだけなので、あらためてsession\_regenerate\_id()しても暗号論的な強度は変わりません。
|
|
27
27
|
|
|
28
|
-
- 守りたい通信が開始するときにセッションを開始する。
|
|
29
|
-
- 守りたい通信が終了したら即座にセッションを破棄する。
|
|
30
|
-
|
|
31
|
-
|
|
28
|
+
なお、セッションの破棄のしかたについては末尾\[1]に補足します。また、今回はログインはしないとのことですが、する場合について\[2]に補足します。
|
|
32
|
-
|
|
33
|
-
なお、ログイン中以外でもセッションを使っているかもしれませんが、ログイン後に同じセッションを使いまわす (session\_regenerate\_id()でIDだけ変える) ように**しない**ほうがいいでしょう。ログインしていない間に攻撃者から情報を注入されたときに、それを信頼してログイン後にも使ってしまうようなコードを書けてしまいます。
|
|
34
|
-
|
|
35
|
-
ちなみに、セッション開始時はsession\_start()だけでいいです。実装上は、IDを生成するたびにOSの(疑似)乱数生成器を使っているだけなので、あらためてsession\_regenerate\_id()しても暗号論的な強度は変わりません (なお、セッションの破棄のしかたについては末尾\[1]に補足します)。
|
|
36
29
|
|
|
37
30
|
次に、セッション中のセッションID再生成について考えます。
|
|
38
31
|
|
|
@@ -75,3 +68,14 @@
|
|
|
75
68
|
|
|
76
69
|
まずセッションデータを消しておかないと、セッションを破棄するまでの間にcookieを送り込まれる可能性があります。ですので、厳密にやるのなら上のようになります。
|
|
77
70
|
|
|
71
|
+
\[2] ログインする場合について補足します。
|
|
72
|
+
|
|
73
|
+
まず、セッションの生成と破棄ですが、次の原則を守るべきです。
|
|
74
|
+
|
|
75
|
+
- 守りたい通信が開始するときにセッションを開始する。
|
|
76
|
+
- 守りたい通信が終了したら即座にセッションを破棄する。
|
|
77
|
+
|
|
78
|
+
つまり、基本的には**ログイン成功したときにsession\_start()し、ログアウトしたらすぐにsession\_destroy()する**ようにします。
|
|
79
|
+
|
|
80
|
+
なお、ログイン中以外でもセッションを使っているかもしれませんが、ログイン後に同じセッションを使いまわす (session\_regenerate\_id()でIDだけ変える) ように**しない**ほうがいいでしょう。ログインしていない間に攻撃者から情報を注入されたときに、それを信頼してログイン後にも使ってしまうようなコードを書けてしまいます。
|
|
81
|
+
|