1


セッションハイジャックを防ぐために、ユーザーエージェントとIPアドレス の変数に基づいて、各ユーザーに特定のCookie名を割り当てようとしました。

次の関数を使用して、セッションIDを保持するセッションCookie名を生成しました。

static function getSessionName(){
    $id= @md5(base64_encode(self::$secretToken.$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]));
    while(is_numeric($id{0})){
        $id = substr($id, 1).$id{0};
    }
    return $id;
}

これは、私のWebサイトにアクセスするすべてのユーザーが、異なるセッションCookie名を持つことを意味します。ハイジャック犯が自分のユーザーエージェントを被害者のユーザーエージェントに変更しない限り、他人のCookieを使用することをブロックします。ユーザーのインターネットモデム、ルーター、NATなどを使用するなど、被害者のIPアドレスを使用してオンラインで表示しようとします。

例を使って説明しましょう。したがって、2人のユーザーが同じブラウザを使用し、同じIPアドレスから接続する場合、同じCookie名を取得します（f5e30acc605e938b097dee73c0272470と想定）。

これで、スクリプトはこれら2つのクライアントでf5e30acc605e938b097dee73c0272470という名前のCookie内のセッションIDを探します。この状態では、クライアントの1つが他のCookieを乗っ取ることができます。同じIP、同じユーザーエージェント、そして同じCookie名！

この方法は良いですが、完全に安全ではありません。ユーザーエージェントの変更はそれほど難しくありません。被害者とハイジャック犯は、コフェネットやパブリックホットスポットなどのパブリックネットワークから接続する場合、同じIPアドレスを持っている可能性があります。

特に「RememberMe？」を使用する場合は、攻撃者がそうすることを拒否することが重要です。長期的なセッションCookieを生成するオプション。

誰かがこの問題について提案がありますか？

私が調査したところ、解決策の1つはSSLと安全なCookieを使用することでした。しかし、SSLを使用しないソリューションを探しています。

4

1 に答える 1

1

という仮定に基づいてシナリオを作成している場合

1) 攻撃者は同じ IP アドレスを持つことができます。2) 攻撃者は、ネット上で送信されるあらゆる情報にアクセスできるため、同じユーザー エージェントを持っているふりをすることができます。

その場合、この Cookie の身元を確認する方法はありません。これは、このすべての情報が利用可能であると想定しているためです。

解決策は 2 つあります。a) SSL を使用する b) ユーザーが攻撃者と同じコーヒー ショップにいるわけではないこと、IP アドレスが有効であること、サイトがまだ大規模な攻撃に値するほど重要ではないことを信頼すること. 彼らはまだ何をすることができますか - 攻撃的な投稿やスパムを作成しますか? とにかく、彼らは自分のアカウントでそれを行うことができました.

私の経験と読んだことから、「時期尚早の最適化は [プログラミングの最大の悪の 1 つ] である」という声明に同意します。機能し、人々にとって役立つサイトを構築することに時間を集中し、何か問題が発生し始めた場合は、SSL 証明書の取得を検討してください。証明書を取得するためのお金がなく、サイトがまだ成功していないため、お金がありません (最初にそれを行います)。

「時期尚早の最適化」とパラノイアなセキュリティ対策は、プログラマーにとって魅力的です。なぜなら、私たちは自分たちが大規模で非常に重要なプロジェクトに取り組んでいなくても [まだ]取り組んでいると考えたいからです。

于 2012-09-22T15:46:37.090 に答える