確認画面からの遷移時に $_SESSION で値を渡すことの意味

Question

投稿フォームなどの古典的パターンとして

・入力画面

・確認画面
・完了画面

の3つの画面を作り、

・入力画面 → 投稿フォーム

・確認画面 → POST or GET でフォーム内容を受取。$_SESSION へ保存
・完了画面 → フォーム内容を $_SESSION で受取

というモノがあると思いますが、完了画面への情報伝達に、$_SESSION を使用するのは、セキュリティ的な意味があるのでしょうか？

投稿内容であれば、ユーザの参照・改竄を気にする必要性を感じないため、hidden で良い気がします。

今時3画面使って投稿なんてしないよ！ってそもそも論もありそうですが、ご教示いただけると幸いです。

Answer 1

セッションに格納するメリット

• 明示的にトークンで対策していなくても，単純に一発本家のURLを踏むだけでアウトになるパターンは免れることができる。（但し，第三者のサイトに仕掛けられた**「確認画面と実行画面のURLをiframeにて時間差で読み込む」**などのURLを踏んでしまうとアウト。結局不完全な対策に過ぎない）
• 2回目のバリデーションは「セッションに値が入っているか」だけで済む。

HTMLに書き出して再度送信させるメリット

• サーバサイドのステート数が減少し，プログラム全体の見通しが良くなる。

個人的にはもちろん後者が好みです。CSRF対策を完璧にしようと思ったらトークンは不可欠ですし，バリデーションロジックを共通化しておけば余分にコードを書く必要もないからです。

セッションにいったん入れておくというやり方を助長しているのは，**「確認画面にはそれ専用のPHPファイルを用意する」（画面とファイルが1対1で対応する）**というやり方が入門書で採用されやすい，という背景もあるでしょう。バリデーションロジックの共通化，なんでもないように見えますが，初心者からすると少々面倒なものかもしれません。

もとより，入力画面と確認画面を分けなければいいだけの話なんですが，HTMLのbody要素の中にロジックごと書き殴っていくタイプのやり方だと出し分けも難しいでしょう。これはもう完全に本が悪いのですが，PHP関連書籍は平均的に著者の技術力が低いというのも影響していそうですね…

Comments

[退会済みユーザー]

やっぱり「入力画面と確認画面を分けなければいいだけの話」なんですよね。

確認画面を必要としない投稿フォームを作成していたのですが、「そういえば、わざわざ確認画面を用意するフォームの意図を正確に理解していない気がする。」というのが、今回の質問のトリガーだったので、非常にしっくりきました。

回答ありがとうございました。

[ockeghem]

分かって書いておられるのだとは思いますが、セッション変数に値を保持しても、CSRF対策としては意味があるのは、攻撃者がよほどしょぼい場合だけかと思います。

[mpyw]

そうですね，ちょっと語弊がありそうなので訂正入れておきます

Answer 2

完了画面への情報伝達に、$_SESSION を使用するのは、セキュリティ的な意味があるのでしょうか？

セキュリティの観点からは、その方法を使うことで得られるメリットは多くないと思います。「CSRF対策でセッションを使用したから、フォームの内容もセッションで管理してしまおう」という判断なのか、「hidden属性を使うと入力チェックが再び必要になるのが面倒だ」と考えたのか、いずれにせよ、セキュリティとはあまり関係のないところでセッションを使うことを決めているのではないかと。

投稿内容であれば、ユーザの参照・改竄を気にする必要性を感じないため、hidden で良い気がします。

hidden属性、セッションのどちらを用いる場合でも不正な値が入力されることや、入力した値が参照･改竄されることは考慮していなければならないので、適切に検証やエスケープなどの処理が行えるならばどちらを用いても問題はないように感じます。個人的にはhidden属性を使うほうが好みですが...。

Comments

[退会済みユーザー]

私の感覚と非常に近いので受け入れやすいのですが、なんとなく世の中の論調は違うような気がするんですよねぇ＾＾；
わざわざ $_SESSION を利用するように指示するサンプル提供サイトも多いので、なんか意味があって見落としてるんじゃないかと思い質問しています。。。

セキュリティと関係ないところの判断なんですかね？

回答ありがとうございます！

Answer 3

私自身は入力内容をセッションに入れない派なので推測ですが、

・バリデーションの回数を減らす
・完了画面で入力内容に基づいた表示をしたい

ではないかと

前者はすでに回答がありますね

後者は、完了画面をリダイレクト表示する場合に必要になるかと

あるいは、単にステートフルな開発に慣れた人がWEB開発に来ただけかもしれませんね

Comments

[退会済みユーザー]

回答ありがとうございます。

ということは、こちらも「セキュリティ的な意義は無い」という回答ですね＾＾；

[takaboo]

ログイン環境であればまだしも、非ログイン環境の場合はむしろ大量のセッションデータを作成されるリスクがありますね

例えばmemcachedにセッションを保管している場合、デフォルトの64MB程度のキャッシュ領域ならあっという間に埋め尽くせそうです
あるいはlinuxでtempfsの/tmpにファイルでセッションを保管している場合ならメモリーを食いつくしてスワップさせることができるかもしれません

[退会済みユーザー]

そうなんですよねぇ。それもあって、なんで $_SESSION にこだわるのか不思議で。。。
世に出回っている情報と、ここの回答の乖離も非常に不思議です＾＾；

Answer 4

Formデータだけで投稿できる場合、なりすまし投稿が可能となります。
そういう掲示板Aがあるとして、被害者Xさんが、悪者Yさんのウェブページを踏んでしまった場合、XさんのブラウザからYさんの意図通りの投稿をAに対して行わせることが出来ます。XさんがAの存在を知らなくても可能です。
犯罪予告が投稿され、警察が投稿者のIPアドレスを調べて身元を割り出して、Xさんを逮捕するとかあり得ます。まあ、最近は警察もこういうことがあり得ると知っているので、すぐに逮捕は無いでしょうけど、有力容疑者なので取り調べはあるでしょうね。

詳しくは、クロスサイトリクエストフォージェリ (cross-site request forgeries) という攻撃手法について調べてみてください。これはセッションを使えば即解決すると言うことでは無く、ちゃんと対策が必要です。

Comments

[退会済みユーザー]

CSRF 対策とは分けて考えていたのですが、あわせて考えたほうがイイんですかね？
CSRFはそれなりに理解できてきていると思います。
CSRF 対策をした場合ですが、CSRF用のトークンを hidden で POST する方法があると思います。であれば、フォームの内容も別に $_SESSION に入れなくても良いのではないかと思うのですが、どうでしょうか？

[otn]

hiddenともう一つの情報を比べて合致するかどうか判断が必要です。

[退会済みユーザー]

トークンを hidden で渡す CSRF対策であれば、確認画面から完了画面に遷移する際、以下のようなやり取りになると思います。

1.サーバ側で token と何らかのID（session id とか）を作成＆紐付け。
2.IDを Cookie に、token を hidden へ埋め込み、ブラウザへ。
3.Cookie の ID と hidden の token が整合性がとれているか検証。

となると、別に 2 で hidden に投稿内容を入れていても、問題ないのではないかと思います。改ざんの可能性はありますが、この場合は、投稿者が改ざんするわけで、問題になることは無いかと。

どうでしょうか？

[otn]

セッションをCookieで管理すればそれでも良いと思います。
質問を誤解していたのかもしれません。
「セッションは不要では？」という質問じゃなくて「セッションを管理するのは$_SESSIONであることは必須か？」という質問であるのなら、必須でないと言うことだと思います。

[退会済みユーザー]

セッションの要不要というよりも、
「セキュリティ観点で、確認画面から完了画面への情報伝達に、$_SESSION を使うこと事は意味はあるのか？」というのが疑問に思っているポイントです。

もう一歩進んだ言い方をすると
「確認画面から完了画面への情報伝達で、サーバサイドに情報を保管しなければならないセキュリティ的な考慮点があるのか？」という疑問です。

何か気にすべき点があれば、教えていただけるとうれしいです。
うまく伝えられなくてすみません＾＾；

[otn]

先ほど書いた通り、Cookieでセッション管理しても良いと思います。
セッション管理できておりCSRF対策できているのであれば、投稿テキストはFormのhiddenからの受け取りでも良いと思います。

サーバー側で保持している例をよく見かけると言うことであれば、強いてFormのhiddenにする積極的な理由が無いので、サーバー側で保持しているということでは無いかと思います。同じデータを、確認のために人間が見る用とhidden用と2つ送信するのがちょっとやな感じもしますし。

[退会済みユーザー]

サーバ側に保持しなければならない意味はないっぽいですね。

意味あるよ！って回答を見てみたいので、しばらくオープンにしておきますが、回答ありがとうございました。

Answer 5

ご回答いただいた方、ありがとうございました。

私としては、「セキュリティ観点で、確認画面から完了画面への情報伝達に、$_SESSION を使うこと事は意味はある」という回答を期待しての質問だったので、正直、困惑していますが、頂いた回答は非常に私自身の感覚と近いので理解しやすかったです。

もし、「$_SESSION を使うこと事にセキュリティ的な意味がある」という回答をお持ちの方がいれば、追記いただけるとうれしいです。

追記 2018/02/22

teratailの質問を見ていて、PHPでログイン機能を作る際に、入力されたIDとパスワードをまずセッション変数に格納していて、「おいおいそれはだめだ」と思ったけど、どういう経路で漏れるかなと考えているうちに、セッション情報ディレクトリのパーミッションを確認するはめになった

上の tweet みてふと思ったんですが、（あんまりないと思うけど）パスワードを $_SESSION で引き回す場合は、ちゃんと処理しないと、生パスワードがサーバ上に残っちゃったりしますね。。。