セッションに対する最も一般的な攻撃方法はセッション ハイジャックです。これは、攻撃者が他の人のセッションにアクセスするために使用できるすべての手段の総称です。これらすべての方法の最初のステップは、正規のユーザーになりすますために正規のセッション ID を取得することであるため、セッション ID が漏洩しないようにすることが非常に重要です。前のセクションで説明したセッションの公開と固定に関する知識は、セッション ID がサーバーと正当なユーザーのみに知られていることを確認するのに役立ちます。
多層防御の原則 (第 1 章を参照) はセッションに適用できますが、セッション ID が攻撃者に知られてしまうと、目立たないセキュリティ対策によってある程度の保護が得られます。セキュリティに関心を持つ開発者としての目標は、前述の偽装プロセスをより洗練させることです。障害物がどれほど小さくても、アプリケーションが保護することを忘れないでください。
偽装手続きを複雑化させる鍵となるのは検証の強化だ。セッション ID は主な認証方法ですが、他のデータで補足することもできます。使用できるすべてのデータは、各 HTTP リクエスト内のデータのみです:
GET / HTTP/1.1 Host: example.org User-Agent: Firefox/1.0 Accept: text/html, image/png, image/jpeg, image/gif, */* Cookie: PHPSESSID=1234
リクエストの一貫性を意識し、一貫性のない動作は疑わしいと考える必要があります。たとえば、User-Agent (このリクエストを発行したブラウザの種類) ヘッダーはオプションですが、ヘッダーを発行したブラウザは通常、その値を変更しません。セッション ID 1234 のユーザーがログイン後 Mozilla を使用している場合 Firfox ブラウザが突然 IE に切り替わりましたが、こちらの方が怪しいです。たとえば、この時点でパスワードを要求することでリスクを軽減できますが、同時に、誤ったアラームが発生した場合でも、正規のユーザーへの影響が軽減されます。次のコードを使用して、ユーザー エージェントの一貫性を検出できます:
<?php session_start(); if (isset($_SESSION['HTTP_USER_AGENT'])) { if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])) { /* Prompt for password */ exit; } } else { $_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']); } ?>
IE ブラウザの一部のバージョンでは、ユーザーが通常 Web ページにアクセスするときと Web ページを更新するときに送信される Accept ヘッダー情報が異なるため、一貫性を判断するために Accept ヘッダーを使用できないことがわかりました。
User-Agent ヘッダー情報の一貫性を確保することは確かに効果的ですが、セッション ID が Cookie を介して渡される場合 (推奨される方法)、攻撃者がセッション ID を取得できれば、攻撃者もセッション ID を取得できることは当然です。他のHTTPヘッダー。 Cookie の露出はブラウザの脆弱性またはクロスサイト スクリプティングの脆弱性に関連しているため、被害者は攻撃者の Web サイトにアクセスしてすべてのヘッダー情報を公開する必要があります。攻撃者が行う必要があるのは、ヘッダー情報の一貫性チェックを防ぐためにヘッダーを再構築することだけです。
より良いアプローチは、URL でタグを渡すことです。これは、(弱いとはいえ) 2 番目の検証形式と考えることができます。この方法を使用するにはプログラミング作業が必要ですが、PHP には対応する関数がありません。たとえば、トークンが $token に保存されていると仮定すると、それをアプリ内のすべての内部リンクに含める必要があります。 この配信プロセスの管理を容易にするために、リクエスト文字列全体を変数に入れることができます。この変数をすべてのリンクに追加すると、最初にこの手法を使用しなくても、後でコードを簡単に変更できます。
攻撃者が被害者のブラウザから送信されたすべての HTTP ヘッダーを知っていたとしても、タグには予測不可能なコンテンツが含まれている必要があります。 1 つの方法は、ランダムな文字列をトークンとして生成することです。
ランダムな文字列 (SHIFLETT など) を使用する場合、それを予測するのは非現実的です。このとき、タグを予測するよりもタグをキャプチャする方が便利です。URL でタグを渡し、Cookie でセッション ID を渡すことで、攻撃は両方を同時にキャプチャする必要があります。これは、攻撃者が被害者によってアプリケーションに送信されたすべての HTTP リクエストの生の情報を表示できない場合を除きます。この場合、すべてが公開されるためです。この攻撃は実装が非常に難しく (したがってまれです)、これを防ぐには SSL の使用が必要です。
有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑,而本群集中的多个代理服务器在编辑该值时可能会不一致。
如果你不希望依赖于检查User-Agent的一致性。你可以生成一个随机的标记:
<?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; ?>
这一方法的安全性虽然是弱一些,但它更可靠。上面的两个方法都对防止会话劫持提供了强有力的手段。你需要做的是在安全性和可靠性之间作出平衡。
以上就是PHP安全-会话劫持的内容,更多相关内容请关注PHP中文网(www.php.cn)!