COOKIEにてサイト表示を切り替え時の不正アクセス手段

レンタルサーバーにてサイト制作(HTTPS)
PHPにてMYSQLから会員ID,パスワードを比較し
(複数回ログイン失敗時は特定時間ログイン処理出来ないように設定)
COOKIE['session_check']に照合一致の文字列を有効時間指定で書き込み
ﾃﾞｰﾀが入ってない場合はログインページへ戻るようにしてあります

PHP
1<?php
2 if(!isset($_COOKIE['session_check'])){
3  header("location:../../",replace);
4 }
5 if($_COOKIE['session_check']!="ﾛｸﾞｲﾝOK"){
6  header("location:../../",replace);
7 }
8?>
9

PHPのﾌｧｲﾙはブラウザからは見れないのですが
$_COOKIE['session_check']に「ﾛｸﾞｲﾝOK」と入れればサイト表示が可能とわかります

危険性について何があるのか何かありましたら教えてください
追記(te2ji様指摘から)
※ログインしたことない人が不正にアクセスする手段等おしえてほしいです

PHP:7.1.14

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

回答2件

ベストアンサー

この方法には問題点があります。主な問題点は

第三者がアクセスしても誰からCookieが流出したかがわからない
強制ログアウトが実装できない
ユーザを退会させてログインできなくする事ができない

ということです。

一度ログインできたユーザはCookieの内容を知っているので、ログインフォームが使えなくても直接Cookieを設定することでログインできます。

Cookieの情報は誰でも書き換えることができます。（簡単な方法としては、ページで右クリックして、要素の検証をクリック>コンソールで下の文字列を入力して再読み込みするとパスワードなしでログインできます）

javascript
1document.cookie='session_check=ﾛｸﾞｲﾝOK';

Cookieのようにユーザから送られてくる情報は全て書き換えられるので、信用してはいけません。
PHPでしたらセッションを使ってログイン状態を保存したらいいかと思います。

セッションでも「セッションID」と呼ばれる情報をCookieに保存して、その値でユーザを区別していますが、セッションIDが他の人にバレない限りは安全です。

セッションIDが他の人にバレると、そのセッションIDを自分のブラウザに設定することで、ユーザをなりすますことができますが、それを防ぐためにセッションIDはランダムに生成されている上に長い値になっているので、推測は事実上不可能です。

他の人のセッションIDを当ててなりすましをする攻撃を「セッションハイジャック」と言いますが、使い方を間違えなければ安全なので、心配する必要はありません。

詳しくはQiitaの記事にわかりやすいものがあったので、読んでみるといいと思います。

投稿2018/05/12 23:33

編集2018/05/12 23:42

stmkza

総合スコア478

Dot

2018/05/12 23:43

以前(3年位前)はセッションID方式だったのですが通信状態が良くない所(良くする事は不可能)で使用しているのでスマホからアクセスするとセッションが切れてしまう事が多々ありcookieに戻しています「session_check=ﾛｸﾞｲﾝOK」と判断できる方法が知りたいのですサーバーを管理しているレンタルサーバー会社の人ならわかると思いますがそれ以外の外部からアクセスした方がそれを判定可能か？です

stmkza

2018/05/12 23:46

多分その原因は全てのページで session_regenerate_id()を呼び出しているからだと思います。それを呼び出すのはログイン時とログアウト時だけでいいと思います。外部からアクセスできるかと言われると「普通はできない」ということになりますが、レンタルサーバの脆弱性を使われるとソースコードが読まれることもあります。 https://blog.tokumaru.org/2013/09/symlink-attack.html このようなことが起こるとバレます

Dot

2018/05/12 23:58

レンタルサーバーが完全に信頼できるという前提なら判定は不可能に近いという事で理解してよいでしょうか？

stmkza

2018/05/13 00:02

基本的にはレンタルサーバが安全ならサーバからソースコードを見られることはなくなります。しかし、それでも強制ログアウトができない・不正ログインされた場合に全てのユーザでCookieを変更する(=ログインし直す)必要があるなどの問題点があります。今後、機能を拡張するときにもセッションは必要となりますし、セキュリティ関連の情報もセッションの方が多くありますので、セッションを使うことをお勧めします。

Dot

2018/05/13 00:19

>外部からアクセスできるかと言われると「普通はできない」で少し安心セッションID方式を調べ直してみます解答ありがとうございました

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

$_COOKIE['session_check']に「ﾛｸﾞｲﾝOK」と入れればサイト表示が可能とわかります

これが普通に危険です。
・ログアウトした他人のブラウザからログインできる
・退会後もログインできる
等々

投稿2018/05/12 23:19

編集2018/05/12 23:21

退会済みユーザー

総合スコア0

Dot

2018/05/12 23:21

簡単にサーバーサイドスクリプトにアクセスする手段などあるのでしょうか？

退会済みユーザー

2018/05/12 23:24

別にスクリプト読まなくても、一度でもログインした人なら知り得る情報です。

Dot

2018/05/12 23:25

いえログインしたことない人がこれに気づく方法が知りたいです

退会済みユーザー

2018/05/12 23:46

気がつくかどうかは危険性があるかどうかとあまり関係がないのですけど。。。なんで、こんな未熟な実装にこだわるんでしょうか？提示されたスクリプトから判断すると、初心者だと思いますが、ログインシステムの実装は、かなり高度な知識を必要とします。フレームワークや有名ライブラリを使用することをオススメします。

Dot

2018/05/12 23:59

未熟なのは理解しています今の所この方法しか知らないので知りたいだけです

退会済みユーザー

2018/05/13 00:05

> フレームワークや有名ライブラリを使用することをオススメします。追加です。 https://qiita.com/rana_kualu/items/3ef57485be1103362f56 > 結論 > ソーシャルログインにしとけ。 > どうしても必要ならフレームワーク使え。

Dot

2018/05/13 00:09

よくわからないので勉強しなおしてみます解答ありがとうございました

退会済みユーザー

2018/05/13 00:58

> 未熟なのは理解しています理解していないと思いますよ。 cookie にログイン状態を保存することの問題点はすでに各所で語られており、すでに捨てられた技術です。 cookie に直接ログイン状態を保存する仕組みは、今後、成熟することはありません。 php には、使用に耐えうる session_id を作り出す関数が用意されているので、そちらの使用を前提に学習してください。気になった点を、記述しておきます。・比較には === !== を使用してください。誤動作のもとです。（今回は問題ないですが、!= を無理に使用する意味もありません）・パスワードはちゃんとハッシュ化し、ハッシュ値の比較でログイン処理を行っていますか？質問を見ると生パスワードを取り扱っているように見えます。・ユーザ ID 等を cookie に保存していませんか？ログイン情報と合わせると、他人がログイン可能です。・XSS 対策をしていないと、cookie を使用したシステムは破綻します。つまり session の利用もできません。XSS 対策が出来ているかまず確認してください。

退会済みユーザー

2018/05/13 01:14

某所のセキュリティ会社の検査項目にセッションIDがCOOKIEやURLに付与されてないこと（POSTでおくれ）とかもあるからなぁ・・・

退会済みユーザー

2018/05/13 01:23

> セッションIDがCOOKIEやURLに付与されてないこと（POSTでおくれ）よく分からん。ページ遷移毎に、POST させるってこと？一般的なフレームワーク全滅な気がしますが。。。

Dot

2018/05/13 01:38

>理解していないと思いますよ。 >cookie にログイン状態を保存することの問題点はすでに各所で語られており、すでに捨てられた技術です。 >cookie に直接ログイン状態を保存する仕組みは、今後、成熟することはありませんなるほど 2011年第7刷「よくわかるPHPの教科書」を参考に 2011年からのをずっと使用していたので知りませんでしたありがとうございます！