Q&A
ご回答ありがとうございます。
まさしく私とは逆のアプローチでのご質問ですね。大変参考になります。
特にこれ！といった致命的な欠点がどちらにあるという物でも無いようですね。
他の方のご回答でも頂いていますが、そもそも今時確認画面なんて不要、という感じなんですね。
古い頭なのか確認画面はあるのが当たり前と思っていたのでカルチャーショックを少々感じております（苦笑
Webアプリケーションでよくある
入力画面
↓
確認画面
↓（登録ボタン）
完了画面
のような時に、確認画面から登録ボタンを押して画面遷移と共に裏でDBに登録処理をする場合、確認画面にhiddenで項目を用意しようと思いました。
ただこのとき項目にパスワードなど扱いに気をつけないといけない物がある場合、hiddenではソースから見えてしまうのでまずいかな？と悩んでおります。
ただ見るのは入力したユーザー本人なのでどうなんだろうと思い質問させて頂きました。
hiddenがまずい場合はセッションに格納したりかなとも思ってはおります。
皆様はこのような場合はどう扱われていますか？
###追記
皆様ご回答ありがとうございます。
前提として想定している情報が足りず申し訳ありません。
以下、もう少し詳細な想定しているケースです。
SSLを利用する前提
通信の傍受面に関してはSSLを利用する前提で、今回視野には入れていませんでした。
入力画面
input type="password"を利用し、入力中の画面表示は*で伏せられる
確認画面
こちらも画面上に直接表示はせずダミーで*で伏せる
（もしくはパスワードの項目自体は確認画面の画面上には表示させない）
入力値チェック
◯文字以上◯文字未満、英数字記号のみ、などのバリデーション処理については、入力画面→確認画面、確認画面→完了画面とどちらでも実施します。
hiddenで本機能を実装した場合に書き換えられても問題ない認識です。
利用シーン
会員制のサイトで初回の会員登録としてのシーンです。
この処理でアカウント作成をした後のログイン処理は、初回のみIDとパスワードを入力させ、次回以降はトークンを利用したログインシステムにする想定です。
DBに格納する値
直接格納するのにふさわしくない項目、カード番号やパスワードに関しては暗号化した状態でDBに保管。復号化は出来ない値として保管。
上記のような想定でした。
そして方法が大きく分けて二つあると思っており、
0. hiddenでバトンリレーしてsubmitしサーバーへ渡す
0. セッションに格納してサーバーへ渡す
簡単な項目（セキュリティを気にしないでもいいような項目、例えば商品名とか）であればhiddenで問題ないと思いますが、セキュリティ意識を持たないといけない項目の場合にはどうなのかな？と思った次第でした。
hiddenであればお手軽に実装出来る、セッションでは適切に消去しないと逆に残ってしまいhiddenに比べると実装設計に手間がかかる。
こんなイメージです。
もともと横着（楽を）してhiddenでいいかなと思っており、hiddenに生のパスワードでもいいか？と思ったのですが、何か私の知らないセキュリティリスクがあるかなと思い質問させて頂きました。
皆さんのご回答を受けて、今思っているのは
入力受付後はハッシュ化してhiddenで持ち回る
がシンプルで尚且つ実装が楽かなぁと横着な考えを持っています。
※生の値を持ち回るのはhiddenでもセッションでもよろしくないと思うので、ハッシュ化。
そしてhiddenでもセッションでもセキュリティ面で著しくどちらかが劣るというお話が出ていないことから上記に至っています。
回答7件
0
hiddenがまずい場合はセッションに格納したりかなとも思ってはおります。
仰る通り、セッションに格納するのが最善と思います。
パスワードは入力した本人のみが知る情報ですが、パスワードのやり取りは最小限に抑えるべきです。
入力画面でのみパスワードを通信でやり取りするのであれば、攻撃者がパスワードを盗むには入力画面で盗み取るしかありません。
が、確認画面でもパスワードをやり取りしているのなら、攻撃者は「入力画面」と「確認画面」のどちらか一方から盗み取ればいい為、パスワードを盗まれるリスクが2倍になります。
勿論、どちらの画面でも問題ないように作るものですが、あえてパスワードを通信でやり取りする回数を増やす理由はないと私は考えます。
入力受付後はハッシュ化してhiddenで持ち回る
これはやってはいけない対策だと思います。
ハッシュ値はサーバ側のみが知っていれば良い情報であり、クライアント側に知らせる必要はありません。
DBに保存されているであろうハッシュ値を知らせるのは得策とは思えません。
Re: yoshihiro_yy さん
投稿2017/06/27 04:43
編集2017/06/27 13:35
総合スコア18162
0
ベストアンサー
確認画面から完了画面へのデータの引き渡しに hidden を使用するのはセキュリティ的な意味があるのか？という質問を私もしました＾＾（逆のアプローチですが）
確認画面からの遷移時に $_SESSION で値を渡すことの意味
どちらの方式で行っても、特に問題は無いようです。
投稿2017/06/27 00:35
退会済みユーザー
総合スコア0
私自身が確認画面見るのが嫌いなので、実装するときはたいてい画面遷移なしで作っています。
確認画面は、今となっては技術的に必須では無いものなので、好き嫌いで判断してますねｗ
0
皆様はこのような場合はどう扱われていますか？
SSL (https 通信）の採用一択だと思います。
投稿2017/06/27 00:05
退会済みユーザー
総合スコア0
0
パスワードは入力した本人のみ知っているべき項目なので、
基本はtype=passwordを利用して横から覗かれても分からないようにしていますよね。
再入力時もvalueには何もセットしません。
確認画面でhiddenでも何でもした場合は見せているも同等でtype=passwordの意味がありません。
私の場合は入力項目は全てセッションに入れて確認画面ではパスワードは＊＊＊＊のような表示にします。
万が一、入力ミスがあった場合はログインIDや登録メールアドレスを利用して初期化・再発行をする機能を設けて、
使ってもらいます。
もちろん、そういったパスワード含めた個人情報を入力した利用する画面ではSSL利用が理想です。
投稿2017/06/27 00:16
総合スコア80850
ご回答ありがとうございます。
仰る通りtype="password"を利用する前提でした。
>パスワードは入力した本人のみ知っているべき項目なので、
そう言われてみると、ソースを表示してパスワードが見えてしまうと、セキュリティがどうという以前にユーザーとして気持ち良くは無いかもしれませんね。
0
確認画面にhidden埋込もセッション格納も、生のパスワードを出力・保持しているという意味でリスクがあります。SSLを利用してもリスクが軽減しているだけで、生のパスワードを扱っているという問題が解決していません。
対策
- 確認画面に遷移しない。
パスワードの入力と他項目（確認が必要な項目）の入力画面を分離し、パスワード入力画面では確認画面に遷移しない。
- 確認画面の時点でパスワードをハッシュ化する。
ハッシュ化したパスワードしか扱わない。この場合は入力画面に戻った場合にパスワードが再入力となります。トレードオフですが今どきはセキュリティが優先されるでしょう。
追記：リスクについて
例えばユーザが確認画面で放置した場合、生のパスワードがブラウザにテキストとして出力、
あるいはセッション情報として保持され続けるという状態となります。この状態は望ましくありません。
その他不測な事態の発生などを考えて、生のパスワードを一時的にでも固定されている状態にするのはリスクがあります。
投稿2017/06/27 05:17
編集2017/06/28 01:56
総合スコア372
ご回答ありがとうございます。
そもそも生のパスワードをやり取りしている時点で、という点は確かにと思いました。
入力画面へ戻った際の再入力は問題ないと思うので、ハッシュ化をする前提で改めて考えようと思います。
ハッシュ化で基本的に問題はないのですが、hiddenで持ち回るのであればそれをそのまま保存するのではなく、再ハッシュ化（「ハッシュ化した文字列＋固定文字」で再度ハッシュ化）することを検討したほうがよいと思います。もちろん、認証時は同じ手順で二回ハッシュ化したものと突合します。
0
一度ログインしてしまえば、パスワードが必要になることはないのでは？
ログインしたユーザーIDなどをセッションで引き継いで行くのが妥当です
投稿2017/06/27 02:18
総合スコア114777
ご回答ありがとうございます。
追記しましたが、今回は新規にアカウントなどの情報を作成する画面での想定で、ログインに関しては仰られる通りセッションを利用した方法で初回のみ入力させるような方法にするつもりでいました。
0
別の方法として、確認画面を画面遷移しない(submitしない)で出すという方法だと
確認画面経由時に持つ必要もなくなるんじゃないかなと
投稿2017/06/27 04:29
総合スコア299
ご回答ありがとうございます。
今時は確認画面への画面遷移はしないものなのですね。
Webの基本のしかも古い知識しか無いもので発想がそもそもなかったです。
そういった実装方法も調べてみます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/06/27 13:31
2017/06/27 13:35