具体的には、これは、クライアント セッション Cookie を使用してサーバー上のセッションを識別する場合に関するものです。
Web サイト全体に SSL/HTTPS 暗号化を使用するのが最善の答えであり、中間者攻撃が既存のクライアント セッション Cookie を盗聴できないという最善の保証がありますか?
そして、セッション Cookie に保存されているセッション値自体にある種の暗号化を使用するのがおそらく 2 番目に良いでしょうか?
悪意のあるユーザーがマシンに物理的にアクセスした場合でも、ファイルシステムを調べて有効なセッション Cookie を取得し、それを使用してセッションをハイジャックできますか?
セッション値を暗号化しても効果はありません。セッション Cookie はすでに任意の値であり、暗号化すると、傍受できる別の任意の値が生成されます。
唯一の本当の解決策は HTTPS です。サイト全体で SSL を使用したくない場合 (パフォーマンスに問題がある可能性があります)、機密領域を保護する SSL だけで済む場合があります。そのためには、まずログイン ページが HTTPS であることを確認します。ユーザーがログインするとき、通常のセッション Cookie に加えて、安全な Cookie を設定します (つまり、ブラウザーは SSL リンク経由でのみ送信します)。次に、ユーザーが「機密」領域の 1 つにアクセスしたときに、それらを HTTPS にリダイレクトし、その安全な Cookie の存在を確認します。実際のユーザーはそれを持っていますが、セッション ハイジャッカーは持っていません。
編集: この回答はもともと 2008 年に書かれました。現在は 2016 年であり、サイト全体で SSL を使用しない理由はありません。プレーンテキストの HTTP はもう必要ありません。
SSLは、盗聴攻撃にのみ役立ちます。攻撃者があなたのマシンにアクセスできる場合、私は彼らがあなたの安全なクッキーもコピーできると思います。
少なくとも、しばらくすると古いCookieの価値が失われることを確認してください。成功したハイジャック攻撃でさえ、Cookieが機能しなくなると阻止されます。ユーザーが1か月以上前にログインしたセッションのCookieを持っている場合は、パスワードを再入力してもらいます。ユーザーがサイトの「ログアウト」リンクをクリックするたびに、古いセッションのUUIDが二度と使用されないようにしてください。
このアイデアが機能するかどうかはわかりませんが、次のようになります。セッションCookieにシリアル番号を追加します。おそらく次のような文字列です。
SessionUUID、シリアル番号、現在の日付/時刻
この文字列を暗号化して、セッションCookieとして使用します。シリアル番号を定期的に変更してください。Cookieが5分経過した場合は、Cookieを再発行してください。必要に応じて、すべてのページビューで再発行することもできます。サーバー側では、そのセッションに対して発行した最後のシリアル番号の記録を保持します。誰かが間違ったシリアル番号でCookieを送信した場合、それは攻撃者が以前に傍受したCookieを使用している可能性があることを意味するため、セッションUUIDを無効にし、ユーザーにパスワードを再入力してから新しいCookieを再発行するように依頼します。
ユーザーが複数のコンピューターを使用している可能性があるため、複数のアクティブなセッションがある可能性があることに注意してください。コンピューターを切り替えるたびに再度ログインするように強制するようなことはしないでください。
PHP セキュリティに関する本を読むことを考えたことはありますか? 強くお勧めします。
SSL 認定されていないサイトでは、次の方法で多くの成功を収めています。
同じアカウントでの複数のセッションを禁止し、IP アドレスだけでこれをチェックしていないことを確認してください。代わりに、ログイン時に生成され、ユーザー セッションとともにデータベースに保存されるトークンと、IP アドレス、HTTP_USER_AGENT などでチェックします。
リレーションベースのハイパーリンクを使用する リンクを生成します (例: http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) リンクには x-BYTE (推奨サイズ) のランダムなソルト付き MD5 文字列が追加され、ページのリダイレクト時にランダムに生成されたtoken は要求されたページに対応します。
短寿命のセッション認証 Cookie。上記のように、セッションの有効性への直接参照の 1 つである安全な文字列を含む Cookie を使用することをお勧めします。x 分ごとに有効期限が切れるようにし、そのトークンを再発行し、セッションを新しいデータと再同期します。データに不一致がある場合は、ユーザーをログアウトするか、セッションを再認証してもらいます。
私は決してこのテーマの専門家ではありません。この特定のトピックについて少し経験があります。これが誰かの役に立てば幸いです。
セッションの乗っ取りを 100% 防止する方法はありませんが、攻撃者がセッションを乗っ取る時間を短縮する方法はいくつかあります。
セッションハイジャックを防ぐ方法:
1 - 常に SSL 証明書でセッションを使用します。
2 - httponly を true に設定してセッション Cookie のみを送信します (javascript がセッション Cookie にアクセスできないようにします)。
2 - ログインおよびログアウト時にセッション再生成 ID を使用します (注: 連続する ajax リクエストがある場合、複数のセッションを作成する機会があるため、各リクエストでセッション再生成を使用しないでください)。
3 - セッション タイムアウトを設定する
4 - ブラウザー ユーザー エージェントを $_SESSION 変数に格納し、各リクエストで $_SERVER['HTTP_USER_AGENT'] と比較します
5 - トークン Cookie を設定し、その Cookie の有効期限を 0 に設定します (ブラウザが閉じられるまで)。リクエストごとに Cookie 値を再生成します (ajax リクエストの場合、トークン Cookie を再生成しません)。元：
//set a token cookie if one not exist
if(!isset($_COOKIE['user_token'])){
//generate a random string for cookie value
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
//set a session variable with that random string
$_SESSION['user_token'] = $cookie_token;
//set cookie with rand value
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}
//set a sesison variable with request of www.example.com
if(!isset($_SESSION['request'])){
$_SESSION['request'] = -1;
}
//increment $_SESSION['request'] with 1 for each request at www.example.com
$_SESSION['request']++;
//verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
if($_SESSION['request'] > 0){
// if it's equal then regenerete value of token cookie if not then destroy_session
if($_SESSION['user_token'] === $_COOKIE['user_token']){
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
$_SESSION['user_token'] = $cookie_token;
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}else{
//code for session_destroy
}
}
//prevent session hijaking with browser user agent
if(!isset($_SESSION['user_agent'])){
$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
}
if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
die('session hijaking - user agent');
}
注: ajax リクエストでトークン Cookie を再生成しないでください 注: 上記のコードは一例です。注: ユーザーがログアウトする場合は、Cookie トークンとセッションを破棄する必要があります
6 - 一部のユーザーの IP はリクエストごとに変更されるため、セッションの乗っ取りを防ぐためにユーザーの IP を使用するのは適切なアプローチではありません。有効なユーザーに影響するもの
7 - 個人的にはセッションデータをデータベースに保存します。どの方法を採用するかはあなた次第です
私のアプローチに誤りがある場合は、修正してください。セッションのハイジャックを防ぐ方法が他にもある場合は、教えてください。
Liu、Kovacs、Huang、および Gouda によるこの論文で説明されている Secure Cookie プロトコルを試してください。
ドキュメントに記載されているとおり：
クライアントとサーバーの間で実行される安全な Cookie プロトコルは、認証、機密性、整合性、およびアンチ リプレイの 4 つのサービスを提供する必要があります。
展開の容易さについては、次のとおりです。
効率の点では、私たちのプロトコルはデータベース検索や公開鍵暗号化を必要としません。展開可能性の点では、私たちのプロトコルは既存の Web サーバーに簡単に展開でき、インターネット cookie の仕様を変更する必要はありません。
要するに、それは安全で軽量で、私にとってはとてもうまく機能します.
セッションIDに増分整数を使用しないようにしてください。GUID、またはその他のランダムに生成された長い文字列を使用する方がはるかに優れています。
リスクを軽減するために、元の IP をセッションに関連付けることもできます。このように、攻撃者がセッションを使用できるようにするには、同じプライベート ネットワーク内にいる必要があります。
リファラーヘッダーをチェックすることもオプションですが、それらはより簡単にスプーフィングされます.
SSL のみを使用し、セッション ID で HTTP_USER_AGENT を暗号化してリクエストごとに検証する代わりに、HTTP_USER_AGENT 文字列をセッション データベースにも保存します。
これで、ENV'HTTP_USER_AGENT' と比較して、単純なサーバー ベースの文字列しかありません。
または、文字列比較に特定のバリエーションを追加して、ブラウザーのバージョン更新に対してより堅牢にすることができます。また、特定の HTTP_USER_AGENT ID を拒否することもできます。（空のもの、つまり）問題を完全に解決するわけではありませんが、少なくとももう少し複雑になります。
別の方法として、より高度なブラウザ フィンガープリンティング技術を使用し、これらの値を HTTP_USER_AGENT と組み合わせて、これらの値を別のヘッダー値で時々送信することもできます。ただし、セッション ID 自体でデータを暗号化する必要があります。
しかし、これにより処理がはるかに複雑になり、リクエストごとに復号化のための CPU 使用率が上昇します。
保護する方法:
$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;