web-dev-qa-db-ja.com

別のドメインにセッションCookieを安全に設定する最良の方法

現在、http://www.foo.co.ukhttps://secure.foo.comの2つのサイトがあります。

WwwサイトにはSSL証明書がなく、別のドメインにあります。

http://www.foo.co.ukにログインボタンがあります。クリックすると、フォームにhttps://secure.foo.comのiframeが開き、ユーザーがログインすると、そのドメインにセッションCookieが作成されます(foo.com)。

次に、セッションCookieをfoo.co.ukにコピーする必要があります。これにより、http://www.foo.co.uk/setcookie.php?session=abcd1234にリダイレクトされ、Originドメインに同じCookieを設定できるようになります。

これは非常に安全な解決策ではないので、これをより良くする方法を検討しています-私が見つけた最良のアイデアは、HMACのようなものを使用してハッシュをパラメータとともにsetcookie.phpスクリプトに送信することです。次に、Cookieを作成する前に、相手側でそれを確認します。

これは優れていますが、中間者攻撃を防ぐことはできません。 wwwがSSLで保護されていないことを念頭に置いて、これを完全に防ぐことはできないと思うので、次の最良の方法は、ハッシュにタイムスタンプを含めて5分間有効にすることです。

私がこれをより良くする方法について誰かが何かアイデアを持っていますか、またはこのアプローチの落とし穴を指摘しますか?私は最も感謝しています。

8
fire

http://www.foo.co.uk のログインボタンをクリックすると、iframeが開きます

現在のページがSSLサイトにリダイレクトされるように、または新しいウィンドウを開くように、これを変更することを強くお勧めします。ユーザーとして、認証トークンを入力する前にアドレスバーに「https」を表示します。

はい、両方のシステムで同じセッションIDを使用するのは安全ではなく、セッションハイジャックの危険にさらされます。理想的には、同じセッションデータを参照する別の値を生成する必要があります。 PHPを使用しているため、独自のセッションハンドラーを追加するのは簡単です。どちら側が何を他方に読み書きするかを決定する必要があります。 2つのセッションID間でHMACまたはその他の機能マッピングを使用することは、ランダムな新しい識別子を作成してデータ内の2つのセッションをリンクすることほど安全ではありません。

2
symcbean

すでに暗号化されていないwwwサイトでこのトークンを作成すると、攻撃者はトークンを暗号化されていないサイトに転送したときに盗聴して暗号化されたサイトで使用することができるため、SSLを介して実行するメリットは実質的になくなります。ユーザーになりすます。

また、暗号化されていないサイトからログインした暗号化されたサイトへのリンクがあると、攻撃者が自分のサイトにリクエストをリダイレクトして認証情報を取得するアクティブなMITM攻撃にさらされます。

特に理由がない場合は、両方のサイトにSSLを配置するだけで、上記のリスクを取り除くことができます。 SSLをどこでも(パフォーマンス)使用しないという古い主な理由は、サイトがどれほどビジーであるか、負荷が高いかによっては当てはまらない場合があります。

それ以外の場合は、アーキテクチャによって異なります。たとえば、2つのサイトはデータベースを共有していますか?もしそうなら、ユーザーに2つの異なるセッション値(1つはwww用、もう1つはセキュアサイト用)を設定して、それらをそこで関連付けることができますか?

4
Rory McCune