web-dev-qa-db-ja.com

PHP）のセッションとCookieを使用して安全なログインを作成する

できるだけ安全にしたいログインスクリプトを作成しています。問題は、セキュリティは終わりのない戦いのようだということです。だから本質的に、私は自分のアイデアに対する提案と改善を探しています。

私が持っているのは、セッションのみに基づくログインです。セッション情報が変更されるたびに、明らかなハイジャックの試みを回避するためにsession_regenerate_id()が呼び出されます。

セッションが設定されていない場合は、Cookieで有効なログインを確認し、成功したらセッションを更新します。

ハッシュ値と一意のユーザー情報（ユーザー名やIDなど）を追加して、Cookieを保護しようとしています。このハッシュは、ユーザー名/ ID、解読できないパスワードハッシュ、IPアドレスの一部など、さまざまな情報で構成されています。Cookieからユーザー名/ IDを抽出することで、有効なユーザー情報から新しいハッシュを作成し、それを比較できます。クッキーにハッシュを入れます。ここでの私の希望は、偽のCookieとCookieのハイジャックを防ぐことです（IPアドレスをスプーフィングしない限り）。

[〜＃〜] edit [〜＃〜]ログイン自体はHTTPS/SSL経由で行われるため、転送は（合理的に）安全であると想定します。

私は正しい方向に進んでいますか？ログインを保護するために他に何ができますか？

助けてくれてありがとう！

phpsecuritysessionauthenticationcookies
15
steveo225

SSLのみで送信されない限り、安全なCookieなどはありません。永続的な非セッションCookie（私を覚えているなど）を使用する場合は、実行していることを正確に実行することで軽減できますが、考えている方法とは異なります。

実際、user-agent、ipアドレスなどのサーバー変数（さらにはJavaScript変数）を保存できますが、これらは永続的なCookieデータがクライアントの新しい接続と一致することを検証する場合にのみ役立ちます。クライアント（あなただけのように）がページの読み込みごとに変更されないことがわかっている場合を除いて、IPアドレスはお勧めできません（AOL）。

最新のWebブラウザやLastPassなどのサードパーティサービスは、ログインフォームにデータを送信するためにキーを押すだけでよい（場合によってはそれさえも必要としない）ログイン資格情報を保存できます。永続的なCookieは、他の方法で利用できるものの使用を拒否する人々にのみ適しています。結局、永続的な非セッションCookieは実際にはもう必要ありません。

3
RT Cunningham

あなたがしていることをやめなさい。 user-agentまたはIPアドレスを確認しないでください。ユーザーエージェントは攻撃者が制御する変数であり、この値をチェックしてもこのシステムのセキュリティは向上しません。ユーザーがロードバランサーやTORの背後にいる場合など、正当な理由でIPアドレスが変更されます。

セッションIDは常に cryptographic nonce である必要があります。 PHPでは、session_start()を呼び出してから、$_SESSIONスーパーグローバルの使用を開始します。 PHPがこれらすべてを処理します。phpのセッションハンドラーを改善したい場合は、 構成 を使用してください。use_only_cookies、cookie_httponly、およびcookie_secureを有効にします。entropy_fileも設定します。 * nixシステムを使用している場合は、/dev/urandomを使用することをお勧めしますが、Windowsの下にある場合は、問題が発生します。

たとえば、ユーザーを認証するには：

//In a header file
session_start();
...
if(check_login($_POST['user_name'],$_POST['password'])){
   //Primary key of this user
   $_SESSION['user_id']=get_user_id($_POST['user_name']);
   $_SESSION['logged_id']=True;
}

また、ユーザーがログインしているかどうかを確認するには、次のようにします。

//in a header file
session_start()
...
if(!$_SESSION['logged_id']){
   header("location: login.php");
   die();//The script will keep executing unless you die()
}

このシステムを改善するには、OWASP A9を読み、セッションの全期間にわたってHTTPSを使用します。また、OWASP A5：CSRF別名「セッションライディング」とOWASP A2：XSSもお読みください。どちらもセッションの侵害に使用できるためです。

6
rook

私は（setcookie関数を使用して）Cookieベースの方法を使用していますが..。

session_start();
...
if(check_login($_POST['user_name'],$_POST['password'])){
   //Primary key of this user
   $_SESSION['user_id']=get_user_id($_POST['user_name']);
   $_SESSION['logged_id']=True;
}

...これらのメソッドは間違っています!!!!

私はクッキーに基づく攻撃で自分のウェブサイトをクラックします。

  1. WebCruiser脆弱性スキャナーのCookieオプションを使用したので、ログイン後にCookieを取得します。
  2. 次に、Cookieの単純な値を変更しました
  3. 次に、[Cookieを保存]をクリックしました。
  4. この時点で、左側のパネルに表示されているWebブラウザーをクリックし、次に右クリックしてから[更新]ページをクリックしたので、ユーザーとパスワードを使用してログインページを使用せずに管理ページを取得しました。

したがって、誰かがウイルスをプッシュしてIEまたはFirefoxのCookie履歴を読み取る場合、管理者ユーザーを見つけて、他のユーザーがパスを使用できることを嬉しく思います。

では、どのように問題を解決するのでしょうか？シンプル：Cookieをセッションサーバーと組み合わせるか、セッションのCookieをセッションサーバーと組み合わせるか、セッションをファイルセッションと組み合わせるか、Cookieをファイルセッションと組み合わせる....安全ですが低速です：（（（（

1
user1628177

SESSIONはCookieよりも安全です。私のアドバイスは、次のように試行された現在のログインに対して一意のIDを作成することです。

$id = uniqid();
$_SESSION['username'.$id] = "something ...";
0
Ali Al-Naimi

私はすべてのログインデータをユーザーセッションに保持します。これにより、すべてのサーバー側に保存されます。

クライアントCookieに保存するのは、「自動ログイン」、「セッションID」などだけです。

0
dbers