入力されたEmailとパスワードをまずセッション変数に格納するのはまずい？

PHPでログイン機能を作る際に、入力されたEmailとパスワードをまずセッション変数に格納することは
セキュリティー的にやめた方がよいでしょうか？

ログインフォーム→ログインチェック→ログイン成功

例: login_check.php

php
1$email = filter_input( INPUT_POST, "email" );
2$password = filter_input( INPUT_POST, "password" );
3
4$_SESION['email'] = $email;
5$_SESSION['password'] = $password;

m.ts10806

2018/02/22 05:05

格納する用途は何でしょうか。また、「まずいのでは」と思われたキッカケや参考記事などあれば。

m.ts10806

2018/02/22 05:12

「email」と「ID」ではそもそもの概念が変わってくるので用語と用法は統一された方が良いかと思います。

行動規範の内容に同意します

回答4件

セッションは（デフォルトでは）ファイルとして書き込まれて情報が保持されるようになっています。

[PHP] リクエストパラメータ・セッションに関するまとめ - Qiita

生のパスワードがコンピュータ上に保持されるのは可能な限り短い時間にしておくべきです。理想は、PHPがリクエストを受け付けたとき、メモリ上に一時的に存在しているだけに留まることです。もしセッションに入れてワンクッション置く必要がある場合は、最初にメールアドレスとパスワードの検証結果のみを格納して、パスワードそのものを格納することは避けるべきでしょう。

【備考】

Aの「事前に生成したユーザごとのパスワードハッシュの配列」は、実際にはデータベース上に保存されるべき情報です。これに関してはBの記事が参考になります。

【追記】

入力されたEmailとパスワードをまずセッション変数に格納する

そもそもなぜパスワードを格納する必要があるんでしょうか？どんなコードを書いたらそうなるのかわかりません…

投稿2018/02/24 18:25

編集2018/02/24 18:26

mpyw

総合スコア5223

退会済みユーザー

2018/02/25 02:58

このしとは・・入力中の情報入力画面→POST ( $_POST から $_SESSION にいれかえる ) → エラーによりredirect（GET)→入力情報をセッションから復元みたいなことをやってたと思う

mpyw

2018/02/25 04:19 編集

あーなるほど、理解です。でもパスワードって普通そういうとき復元対象から外しますよね…

行動規範の内容に同意します

ベストアンサー

まずいです。
何かの問題でプロセスの中のデータを覗かれた場合、パスワードが見えてしまいます。
プロセスの中を覗かれている時点で致命的ではあるのですが、パスワードが見えてしまうと、そのパスワードで他のサイトにも入り込まれます。たとえば、公共の場所にある端末からどこかに入り込む時です。公共の端末には何かバックドアがあって、全ての変数を記録するようになっているかもしれないです。パスワードっぽい変数名のみ記録して、１週間に一度だけ記録を確認する　といった攻撃側の運用もあります。

PHPに限らず一般のプログラムでどうしても一時的に保持する必要がある場合は、暗号化している例もあります。コンセプト的には、mask = datetime().. tmppasswrd = keyin() ^ mask ;　みたいにすれば、多少はマシになります。 maskの値は、一回限り使う値で、他の部分でも使いそうな値が望ましいと思います。

投稿2018/02/27 08:09

gm300

総合スコア580

mpyw

2018/02/28 16:11

プロセス以前にセッションに入れる時点でファイルに出力されちゃうんでもっとヤバいですね

行動規範の内容に同意します

どういう目的でパスワードをセッション変数に格納したいのですか？

セキュリティ的にはやめたほうがいいし、そもそも「ログインチェック→ログイン成功」ならばそうする必要がないのですが。

投稿2018/02/26 23:59

zico_teratail

総合スコア907

セッションハイジャックより引用

HTTPセッション

HTTPはもともとブラウザの要求に対してWebページを返すような一往復の通信が想定されており、HTTPそれ自身はセッション管理の仕組みを備えていないため、Webアプリケーションの側でセッション管理の仕組みを用意し、ブラウザ側にセッションIDを持たせる必要がある。しかしこのセッション管理の仕組みが不適切であると、セッションをハイジャックされてしまう危険がある。

Webアプリケーションに対するセッションハイジャックは以下の三種類に分類できる[1][2]：セッションIDの推測、セッションIDの盗み出し、セッションID固定化攻撃。第一の方法であるセッションIDの推測は、セッションIDを推測しやすい方法で割り振っている場合に可能な攻撃で、例えばセッションIDを連番、時刻[3]、ユーザID[3]、メールアドレス[3]といったものにしていると、攻撃者にセッションIDを推測される危険がある。

第二の方法であるセッションIDの盗難は、Webアプリケーションの脆弱性（例えばクロスサイトスクリプティング[1]、HTTPヘッダ・インジェクション[1]、ミドルウェアの脆弱性[1]）がある場合に可能な攻撃で、これらの脆弱性を利用してブラウザに保管されたセッションIDを盗む。またセッションIDをURLに埋め込んでいるケースではリファラを悪用した以下のような盗難方法が知られている[4]：例えばSNSのユーザのセッションをハイジャックする場合、攻撃者は標的となるユーザに自身のサイトへのリンクをSNS経由で伝える。ユーザがSNS上のリンクをクリックして攻撃者のサイトにアクセスすると、攻撃者のサイトにはユーザが直前にいたサイト（すなわちSNS）のURLがリファラとして伝わるので、SNSのサイトでセッションIDをURLに埋め込んでいる場合には、攻撃者にセッションIDが知られてしまう。

投稿2018/02/24 16:54

退会済みユーザー

総合スコア0