PHP セキュリティ



以下のCookieを使ってログインを維持する仕組みはセキュリティの観点から問題ありますでしょうか?

●ログインプロセス
1)ユーザーがIDとパスワードを入力
2)DBを照会し、合っていた場合はハッシュキーを発行。
  DB側にそのハッシュキーを維持
3)2)で発行したハッシュキーをユーザーに対してCookieで付与

ログイン完了

●ログイン確認プロセス
1)Cookieに文字列があるか確認
2)文字列がある場合はその文字列をDBから検索
3)文字列がDBに保存されている場合、新しいハッシュキーを発行し、DBとユーザーのCookieを更新。ログインOKと表示。
文字列がDBに保存されていない場合はログインしていないと判断。

この場合、ログイン維持に全てCookieを利用しており、セッションは使っていません。

ユーザーは毎回アクセスする度にCookieで保持しているハッシュキー(Token)が更新され一応これでセキュリティは保持しているつもりです。

大きな欠陥などあれば教えてください。

回答の条件
  • 1人1回まで
  • 13歳以上
  • 登録:2016/07/12 22:57:59
  • 終了:2016/07/19 23:00:03

回答(1件)

id:pyopyopyo No.1

pyopyopyo回答回数333ベストアンサー獲得回数782016/07/13 02:38:04

ポイント100pt

ログインプロセスの2)で,ハッシュキーはどうやって計算しますか?
ハッシュキーが予測可能だと,それがセキュリティホールになります


いわゆるセッションを自前で実装したように見えますが,なぜPHP標準のセッションを使わないのでしょうか?

他2件のコメントを見る
id:TransFreeBSD

横からですが。
sessionもキー(sid)を共有するのにcookieを使ってますよ。
そのため、改竄が無意味となるようランダムキーを使うわけで。

今回のはセッション機構の一部を自前で構築しようという話ですが、通常はこなれているphpのsessionを使った方が穴が少ない気がします。
ただ、phpのsessionも多数の環境で動くように妥協したり、汎用性を持たせるために複雑な部分があるので、単純で見通しの良い実装を慎重に構築すれば性能もセキュリティも確保出来るかもしれません。
でも出来ないかもしれません。

そこまでセキュリティに気を使うのであれば専門書やこなれた実装を探す方が良い様に思います。
それに、穴はこういった部分にもありますが、ユーザー側の取扱いとかサーバへの物理アクセスとか他にも大穴が開いている事も珍しくないですし、トータルで考えないと無意味になってしまいますよ。

2016/07/16 13:59:27
id:tobeoscontinue

DBに保存されたハッシュキーを削除する条件はどうなっているのでしょう。
クライアントがもう使っていないハッシュキーがDBに存在し続けるとDB内に
大量のハッシュキーがたまってしまい攻撃に対して弱くなってしまうように思います。

2016/07/18 16:54:51

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません