php sessionハイジャックと防犯方法
4022 ワード
セッションデータ露出セッションデータには、個人情報やその他の機密データが含まれることが多い.このため,セッションデータの露出は普遍的に関心されている問題である.一般に、セッションデータはデータベースやファイルシステムではなくサーバ環境に保存されるため、露出の範囲は大きくありません.したがって,セッションデータは当然公開されない.
SSLを使用することは、サーバとクライアントの間でデータが転送される際に露出する可能性を最小限に抑えることができる特に有効な手段です.これは機密データを転送するアプリケーションにとって非常に重要である.SSLはHTTPの上に保護層を提供し、HTTP要求と応答中のすべてのデータを保護する.
セッションデータ保存領域自体のセキュリティに関心がある場合は、セッションデータを暗号化することで、正しい鍵がなければコンテンツを読み取ることができません.これはPHPで非常に簡単です.sessionを使うだけです.set_save_handler()は、自分のsession暗号化ストレージと復号読み出しの処理関数を書けばいいです.
セッションハイジャックで最も一般的なセッションに対する攻撃手段はセッションハイジャックである.それはすべての攻撃者が他の人の会話にアクセスできる手段の総称である.これらの手段の最初のステップは、合法的なセッションIDを取得して合法的なユーザーに偽装することであるため、セッションIDが漏らされないことを保証することが重要である.前のセッションの暴露と固定に関する知識は、セッションIDがサーバと合法的なユーザーだけが知ることができることを保証するのに役立ちます.
深度防犯の原則はセッションで使用でき、セッション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(このリクエストを発行するブラウザタイプ)ヘッダはオプションですが、ヘッダを発行するブラウザであれば、通常は値は変更されません.1234のセッションIDを持つユーザーがログインしてからMozilla Firfoxブラウザを使っていて、突然IEに変換した場合、疑わしいです.たとえば、パスワードの入力を要求する方法でリスクを軽減し、誤報時に合法的なユーザーに与える衝撃も小さくなります.次のコードを使用して、User-Agentの一貫性を検出できます.
いくつかのバージョンのIEブラウザでは、ユーザーが正常に1つのページにアクセスし、1つのページをリフレッシュするときに発行されるAcceptヘッダ情報が異なるため、Acceptヘッダは一貫性を判断するために使用できないことを観察したことがある.
User-Agentヘッダ情報が一致していることを確認することは確かに有効であるが,セッションIDがクッキーを介して伝達される(推奨方式)と,攻撃者がセッションIDを取得できれば他のHTTPヘッダも取得できると考えられる.クッキーがブラウザの脆弱性やクロスステーションスクリプトの脆弱性に関連していることを暴露したため、被害者は攻撃者のウェブサイトにアクセスし、すべてのヘッダ情報を暴露する必要がある.すべての攻撃者がしなければならないのは、頭部情報の一貫性の検査を防止するために頭部を再構築することだけです.
比較的良い方法は、URLにタグを渡すことであり、これは第2の検証の形式(より弱いが)であると考えられる.この方法を使用するにはいくつかのプログラミング作業が必要で、PHPには対応する機能がありません.たとえば、タグが$tokenに保存されていると仮定すると、アプリケーションのすべての内部リンクに含める必要があります.
この転送プロセスをより容易に管理するために、リクエスト列全体を変数に配置することができます.この変数をすべてのリンクの後ろに添付することで、最初からこのテクニックを使用していなくても、今後コードを簡単に変更することができます.
このタグには予測不可能な内容が含まれている必要があり,攻撃者が被害者ブラウザから発信されたHTTPヘッダのすべての情報を知っていてもだめである.1つの方法は、タグとしてランダムな列を生成することです.
ランダムストリング(SHIFLETTなど)を使用する場合、それを予測するのは現実的ではありません.この場合、キャプチャタグは予測タグよりも便利になり、URLにタグを渡すこととクッキーにセッションIDを渡すことで、攻撃時に両方を同時にキャプチャする必要があります.このように、攻撃者が被害者があなたのアプリケーションに送ったすべてのHTTP要求の元の情報を見ることができない限り、このような状況ではすべての内容が暴露されているからです.このような攻撃方式を実現することは非常に困難であり(したがって珍しい)、SSLの使用を防止する必要がある.
User-Agentの一貫性の確認に依存しないように警告する専門家がいる.これは、サーバクラスタ内のHTTPプロキシサーバがUser-Agentを編集し、このクラスタ内の複数のプロキシサーバがこの値を編集するときに一致しない可能性があるためです.User-Agentの一貫性のチェックに依存したくない場合は.ランダムなタグを生成できます.
この方法の安全性は弱いが,より信頼できる.上記の2つの方法はいずれもセッションハイジャック防止に強力な手段を提供している.セキュリティと信頼性のバランスをとる必要があります.
SSLを使用することは、サーバとクライアントの間でデータが転送される際に露出する可能性を最小限に抑えることができる特に有効な手段です.これは機密データを転送するアプリケーションにとって非常に重要である.SSLはHTTPの上に保護層を提供し、HTTP要求と応答中のすべてのデータを保護する.
セッションデータ保存領域自体のセキュリティに関心がある場合は、セッションデータを暗号化することで、正しい鍵がなければコンテンツを読み取ることができません.これはPHPで非常に簡単です.sessionを使うだけです.set_save_handler()は、自分のsession暗号化ストレージと復号読み出しの処理関数を書けばいいです.
セッションハイジャックで最も一般的なセッションに対する攻撃手段はセッションハイジャックである.それはすべての攻撃者が他の人の会話にアクセスできる手段の総称である.これらの手段の最初のステップは、合法的なセッションIDを取得して合法的なユーザーに偽装することであるため、セッションIDが漏らされないことを保証することが重要である.前のセッションの暴露と固定に関する知識は、セッションIDがサーバと合法的なユーザーだけが知ることができることを保証するのに役立ちます.
深度防犯の原則はセッションで使用でき、セッション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(このリクエストを発行するブラウザタイプ)ヘッダはオプションですが、ヘッダを発行するブラウザであれば、通常は値は変更されません.1234のセッションIDを持つユーザーがログインしてからMozilla Firfoxブラウザを使っていて、突然IEに変換した場合、疑わしいです.たとえば、パスワードの入力を要求する方法でリスクを軽減し、誤報時に合法的なユーザーに与える衝撃も小さくなります.次のコードを使用して、User-Agentの一貫性を検出できます.
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ブラウザでは、ユーザーが正常に1つのページにアクセスし、1つのページをリフレッシュするときに発行されるAcceptヘッダ情報が異なるため、Acceptヘッダは一貫性を判断するために使用できないことを観察したことがある.
User-Agentヘッダ情報が一致していることを確認することは確かに有効であるが,セッションIDがクッキーを介して伝達される(推奨方式)と,攻撃者がセッションIDを取得できれば他のHTTPヘッダも取得できると考えられる.クッキーがブラウザの脆弱性やクロスステーションスクリプトの脆弱性に関連していることを暴露したため、被害者は攻撃者のウェブサイトにアクセスし、すべてのヘッダ情報を暴露する必要がある.すべての攻撃者がしなければならないのは、頭部情報の一貫性の検査を防止するために頭部を再構築することだけです.
比較的良い方法は、URLにタグを渡すことであり、これは第2の検証の形式(より弱いが)であると考えられる.この方法を使用するにはいくつかのプログラミング作業が必要で、PHPには対応する機能がありません.たとえば、タグが$tokenに保存されていると仮定すると、アプリケーションのすべての内部リンクに含める必要があります.
$url = array();
$html = array();
$url['token'] = rawurlencode($token);
$html['token'] = htmlentities($url['token'], ENT_QUOTES, 'UTF-8');
?>
Click Here
この転送プロセスをより容易に管理するために、リクエスト列全体を変数に配置することができます.この変数をすべてのリンクの後ろに添付することで、最初からこのテクニックを使用していなくても、今後コードを簡単に変更することができます.
このタグには予測不可能な内容が含まれている必要があり,攻撃者が被害者ブラウザから発信されたHTTPヘッダのすべての情報を知っていてもだめである.1つの方法は、タグとしてランダムな列を生成することです.
$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';
$token = md5($string);
$_SESSION['token'] = $token;
?>
ランダムストリング(SHIFLETTなど)を使用する場合、それを予測するのは現実的ではありません.この場合、キャプチャタグは予測タグよりも便利になり、URLにタグを渡すこととクッキーにセッションIDを渡すことで、攻撃時に両方を同時にキャプチャする必要があります.このように、攻撃者が被害者があなたのアプリケーションに送ったすべてのHTTP要求の元の情報を見ることができない限り、このような状況ではすべての内容が暴露されているからです.このような攻撃方式を実現することは非常に困難であり(したがって珍しい)、SSLの使用を防止する必要がある.
User-Agentの一貫性の確認に依存しないように警告する専門家がいる.これは、サーバクラスタ内のHTTPプロキシサーバがUser-Agentを編集し、このクラスタ内の複数のプロキシサーバがこの値を編集するときに一致しない可能性があるためです.User-Agentの一貫性のチェックに依存したくない場合は.ランダムなタグを生成できます.
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>
この方法の安全性は弱いが,より信頼できる.上記の2つの方法はいずれもセッションハイジャック防止に強力な手段を提供している.セキュリティと信頼性のバランスをとる必要があります.