PHP セッションのハイジャックと防止方法_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 10:25:22855ブラウズ
セッション データの公開
セッション データには、個人情報やその他の機密データが含まれることがよくあります。このため、セッション データの漏洩は一般的な懸念事項です。一般に、セッション データはデータベースやファイル システムではなくサーバー環境に保存されるため、危険にさらされる範囲はそれほど大きくありません。したがって、セッションデータは当然ながら公開されません。
SSL の使用は、サーバーとクライアントの間で送信される際にデータが公開される可能性を最小限に抑えるための特に効果的な手段です。これは、機密データを送信するアプリケーションにとって非常に重要です。 SSL は HTTP の上に保護層を提供するため、HTTP 要求および応答内のすべてのデータが保護されます。
セッションデータ保存領域自体のセキュリティが心配な場合は、正しいキーがなければ内容を読み取れないようにセッションデータを暗号化できます。これは PHP で行うのが非常に簡単で、session_set_save_handler() を使用し、独自のセッション暗号化ストレージと復号化読み取り処理関数を記述するだけです。
セッションハイジャック
セッションに対する最も一般的な攻撃方法はセッションハイジャックです。これは、攻撃者が他の人のセッションにアクセスするために使用できるすべての手段の総称です。これらすべての方法の最初のステップは、正規のユーザーになりすますために正規のセッション ID を取得することであるため、セッション ID が漏洩しないようにすることが非常に重要です。セッションの公開と固定に関するこれまでの知識は、セッション ID がサーバーと正当なユーザーのみに知られていることを確認するのに役立ちます。
多層防御の原則は、残念ながらセッション ID が攻撃者に知られている場合に、目立たないセキュリティ対策によってある程度の保護が提供される可能性があります。セキュリティに関心を持つ開発者としての目標は、前述の偽装プロセスをより洗練させることです。障害物がどんなに小さくても、アプリケーションが保護することを忘れないでください。
偽装プロセスをより複雑にする鍵は検証を強化することです。セッション ID は主な認証方法ですが、他のデータで補足することもできます。使用できるすべてのデータは、各 HTTP リクエスト内のデータのみです:
GET / HTTP/1.1
ホスト: example.org
ユーザーエージェント: Firefox/1.0
受け入れ: text/html、image/png、image/jpeg 、 image/gif, */*
Cookie: PHPSESSID=1234
リクエストの一貫性を認識し、一貫性のない動作は疑わしいものとして考慮する必要があります。たとえば、User-Agent (このリクエストを発行したブラウザの種類) ヘッダーはオプションですが、ヘッダーを発行したブラウザは通常、その値を変更しません。セッション ID が 1234 のユーザーがログイン後、Mozilla Firefox ブラウザを使用していて、突然 IE に切り替えた場合、これは疑わしいと考えられます。たとえば、この時点でパスワードを要求することでリスクを軽減できますが、同時に、誤ったアラームが発生した場合でも、正規のユーザーへの影響が軽減されます。次のコードを使用して、ユーザー エージェントの整合性を検出できます。
session_start();
if (isset($_SESSION['HTTP_USER_AGENT' ] ; _SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
}
?>
一部のバージョンの IE ブラウザでは、ユーザーが通常、Web ページにアクセスして Web ページを更新することがわかりました。 Web ページによって送信される Accept ヘッダー情報は異なるため、一貫性を判断するために Accept ヘッダーを使用することはできません。
User-Agent ヘッダー情報の一貫性を確保することは確かに効果的ですが、セッション ID が Cookie を介して渡される場合 (推奨される方法)、攻撃者がセッション ID を取得できれば、他の HTTP ヘッダーも取得できることは理にかなっています。 。 Cookie の露出はブラウザの脆弱性またはクロスサイト スクリプティングの脆弱性に関連しているため、被害者は攻撃者の Web サイトにアクセスしてすべてのヘッダー情報を公開する必要があります。攻撃者が行う必要があるのは、ヘッダー情報の一貫性チェックを防ぐためにヘッダーを再構築することだけです。
より良いアプローチは、URL でタグを渡すことです。これは、(弱いとはいえ) 2 番目の検証形式と考えることができます。この方法を使用するにはプログラミング作業が必要ですが、PHP には対応する関数がありません。たとえば、トークンが $token に保存されていると仮定すると、アプリ内のすべての内部リンクにトークンを含める必要があります:
コードをコピーします
コードは次のとおりです:
$url = array() ;
$html = array();
この配信プロセスをより便利に管理するには、リクエスト文字列全体を変数に入れることができます。この変数をすべてのリンクに追加すると、最初にこの手法を使用しなくても、後でコードを簡単に変更できます。
攻撃者が被害者のブラウザから送信されたすべての HTTP ヘッダー情報を知っていたとしても、タグには予測不可能なコンテンツが含まれている必要があります。 1 つの方法は、ランダムな文字列をタグとして生成することです:
$string = $_SERVER['HTTP_USER_AGENT'];
$string 。 = 'SHIFLETT';
$token = md5($string);
$_SESSION['token'] = $token;
?>
ランダムな文字列 (SHIFLETT など) を使用する場合、それを予測してください。このとき、タグを予測するよりもタグをキャプチャする方が便利です。URL でタグを渡し、Cookie でセッション ID を渡すことで、攻撃は両方を同時にキャプチャする必要があります。これは、攻撃者が被害者によってアプリケーションに送信されたすべての HTTP リクエストの生の情報を表示できない場合を除きます。この場合、すべてが公開されるためです。この攻撃は実装が非常に難しく (したがってまれです)、これを防ぐには SSL の使用が必要です。
一部の専門家は、ユーザーとエージェントの一貫性のチェックに頼ることに対して警告しています。これは、サーバー クラスター内の HTTP プロキシ サーバーがユーザー エージェントを編集するため、この値を編集すると、このクラスター内の複数のプロキシ サーバーが矛盾する可能性があるためです。ユーザーとエージェントの整合性のチェックに依存したくない場合。ランダムなトークンを生成できます:
$token = md5(uniqid(rand(), TRUE));
$_SESSION[' token'] = $token;
?>
このメソッドのセキュリティは弱いですが、信頼性は高くなります。上記の方法はどちらも、セッション ハイジャックを防ぐ強力な手段を提供します。必要なのは、セキュリティと信頼性のバランスを取ることです。