回答編集履歴
2
ネストした箇条書きダメっぽい
answer
CHANGED
@@ -1,7 +1,6 @@
|
|
1
1
|
###### セッションに格納するメリット
|
2
2
|
|
3
|
-
- 明示的にトークンで対策していなくても,単純に一発本家のURLを踏むだけでアウトになるパターンは免れることができる。
|
4
|
-
|
3
|
+
- 明示的にトークンで対策していなくても,単純に一発本家のURLを踏むだけでアウトになるパターンは免れることができる。(但し,第三者のサイトに仕掛けられた**「確認画面と実行画面のURLを`iframe`にて時間差で読み込む」**などのURLを踏んでしまうとアウト。結局不完全な対策に過ぎない)
|
5
4
|
- 2回目のバリデーションは「セッションに値が入っているか」だけで済む。
|
6
5
|
|
7
6
|
###### HTMLに書き出して再度送信させるメリット
|
1
徳丸さんから突っ込まれたので
answer
CHANGED
@@ -1,13 +1,14 @@
|
|
1
1
|
###### セッションに格納するメリット
|
2
2
|
|
3
|
-
- 明示的にトークンで対策していなくても,
|
3
|
+
- 明示的にトークンで対策していなくても,単純に一発本家のURLを踏むだけでアウトになるパターンは免れることができる。
|
4
|
+
- 但し,第三者のサイトに仕掛けられた**「確認画面と実行画面のURLを`iframe`にて時間差で読み込む」**などのURLを踏んでしまうとアウト。結局不完全な対策に過ぎない。
|
4
5
|
- 2回目のバリデーションは「セッションに値が入っているか」だけで済む。
|
5
6
|
|
6
7
|
###### HTMLに書き出して再度送信させるメリット
|
7
8
|
|
8
9
|
- サーバサイドのステート数が減少し,プログラム全体の見通しが良くなる。
|
9
10
|
|
10
|
-
個人的にはもちろん後者が好みです。CSRF対策を完璧にしようと思ったらトークンは
|
11
|
+
個人的にはもちろん後者が好みです。CSRF対策を完璧にしようと思ったらトークンは不可欠ですし,バリデーションロジックを共通化しておけば余分にコードを書く必要もないからです。
|
11
12
|
|
12
13
|
セッションにいったん入れておくというやり方を助長しているのは,**「確認画面にはそれ専用のPHPファイルを用意する」(画面とファイルが1対1で対応する)**というやり方が入門書で採用されやすい,という背景もあるでしょう。バリデーションロジックの共通化,なんでもないように見えますが,初心者からすると少々面倒なものかもしれません。
|
13
14
|
|