11

Web アプリケーションに従来の「remember-me」チェックボックスを実装して、認証されたユーザーが Web サイトに戻ったときに「記憶」できるようにすることを検討しています。

Gmail、Facebookなどにはこの種の機能がありますが、どれだけ安全かはわかりません。

Spring Securityのような Java フレームワークは、「ハッシュベースのトークン アプローチ」を使用します。(ユーザー名、パスワード、expirationTime、および privateKey を使用して) 生成されるトークンは、クライアントの Cookie 'token=567whatever567' に格納されます。トークンは、ユーザーが次に戻ってきたときに再認証するために再利用されます。

ログイン プロセスが https 接続で行われた場合でも、その後のすべての http 要求で、Cookie が暗号化されずにネット上に送信されるという事実が懸念されます。

基本的に、誰もがトークンを読み取り、それを再利用して認証できます。

Gmail や Facebook がこの機能をどのように実装しているかを調べようとしています。FB では「presence=DJ267619445G09H0L15228675.....」のような Cookie が表示され、Gmail ではその他の Cookie が表示されます。
他のユーザーになりすまそうとする誰かから保護するために、彼らが他のトリックを使用しているかどうかはよくわかりません.

cURLのようなものを使用して自分自身になりすまして、ユーザーを記憶するために特定のトークンのみを使用しているかどうかを確認します。
もしそうなら、それは私には大きなセキュリティ問題のように見えます. facebook ではないかもしれませんが (私は気にしません)、Gmail では「Use always https」を設定しないと、http 接続が使用され、暗号化されていないトークンがインターネット経由で送信されます。
どう思いますか？

また、Facebook のユーザー名/パスワード フィールドが (https ではなく) http で公開されていることにも気付きました。この点で、私も疑問に思っています.httpでユーザー名/パスワードフィールドを公開しているすべてのWebサイトは、「本質的に」安全ではありません. リクエストが http 経由で送信されると、「世界中に表示される資格情報」の問題を解決できる「https へのリダイレクト」はありません。

ありがとう

編集：
私の心配は十分に根拠がありましたhttp://codebutler.com/問題を強調してくれたFiresheep
の作成者に 感謝します!!!

4

6 に答える 6

7

Remember-meを実装することはそれほど問題ではありません。あなたがする必要があるのは、セッションを長く存続させることです（そしてCookieを長く持続するように設定します）。Gmailでも一定期間（2週間か1ヶ月だと思います）でログアウトします。ただし、同じセッションを開いたままにしておくと、ハイジャックされる可能性が高くなることを理解する必要があります。対策として、セッション識別子の強度を上げる必要があります。セッション識別子は、Cookie（または、一部のソフトウェアで「file.php？PHPSESSID = 1234 ...」として一般的に見られるURI）にあるものです。

重要なのは、強力なセッション識別子を維持することです。たとえば、Gmailには、次のような値のCookieGXがあります。

DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ

セッションハイジャックがほとんど不可能である理由は、セッション識別子が非常に強力であり、サイトがどこでもHTTPSを利用しているためです。だれもあなたのセッション識別子を推測したり取得したりすることはできません（したがって、あなたのセッションに乗っ取ることはできません）。簡単に見ると、上記のセッションIDには、約1250ビットの強度があり、1 * 10^376の異なる可能性があるようです。誰もそれを推測することはできません。

明らかに、セッションにハイジャックする可能性のある方法は常にあります。たとえば、XSSの脆弱性は、Cookie、つまりセッションIDを取得するための扉を開きますが、これはセッションの障害ではなく、「remember-me」とは何の関係もありません。

ログインプロセスがhttps接続で発生した場合でも、後続のすべてのhttpリクエストでCookieが暗号化されずにネット上に送信されるのではないかと心配しています。

HTTPSでCookieセキュアフラグをtrueに設定すると、HTTP経由でサイトにアクセスするときにCookieが送信されることはありません。HTTPSのみのサイトでは必須です。

一般的に、人々はログインページにHTTPSしか使用していないようですが、これは間違っています。本当に気になる人は、ページ全体でHTTPSを使用する必要があります。そうしないと、すべてのセッションハイジャックの試みを防ぐことができません。

なぜ多くの人がログイン部分だけにHTTPSを使用しているのですか？おそらく、彼らが何が問題になっているのかを理解していないか、CPUが重すぎてどこでもHTTPSを使用できないためです。ただし、ログインにはHTTPSを使用する方が、どこにも使用しないよりも優れています。これは、資格情報を暗号化するためです（したがって、セッションIDのみが後で盗まれる可能性があり、ログオン時の実際の資格情報は盗まれません）。

Facebookではないかもしれませんが（私は気にしません）、Gmailでは「常にhttpsを使用」を設定しないとhttp接続が使用され、暗号化されていないトークンがインターネット経由で送信されます。どう思いますか？

可能であれば、値はすべての場合にデフォルトでHTTPSに設定する必要があると思います。HTTPSを使用しない唯一の本当の理由はお金（=パフォーマンス/ハードウェア）です。

于 2010-03-03T19:19:23.233 に答える
3

これは一般にリプレイ攻撃と呼ばれます。攻撃者は、あなたから盗んだのと同じ認証情報 (Cookie など) を使用してリクエストをリプレイし、あなたになりすますことができます。XSS 攻撃はこれのバリエーションにすぎませんが、(HTTPOnly を使用するなどして) 防ぐことができます。

ほとんどのリプレイ攻撃を軽減する唯一の方法は、あらゆる場所で https を使用することです。これにより、ほとんどの詮索好きな目を遠ざけることができます。

予防法もたくさんあります。

ソフトウェアでハッキングするよりも優れた仕事をするハードウェア デバイスもあり、その過程でサーバーの速度が低下します。特殊なハードウェアは、リクエストをリアルタイムで追跡し、同じトークンが多くの異なる IP によって同時に使用されていることを判断するという、はるかに優れた仕事を行うことができます。

ASP.NET 2.0 以降では、フォーム認証を使用するrequireSSL='true'ときに、https 接続が確立されたときにのみブラウザーが認証 Cookie を送信するように指定できます。フォーム認証を保護する方法の詳細については、この msdn の記事を参照してください。

許可しない唯一の理由remember meは、銀行または同様のアプリケーションである場合です。そうでない場合は、いくつかの簡単なルールに従ってください。

  1. 持っている場合はremember me、Cookie の有効期限を最大 30 日後に設定し、値をスライドさせないでください。ユーザーに月に 1 回のログインを強制することは、それほど悪いことではありません。
  2. 機密性の高い操作にはパスワードが必要です。請求、クレジット カード、またはアカウントの詳細を更新するときは、常にユーザーのパスワードを再要求します。悪用の最も可能性の高い形式は、通常、その人物が使用しているのと同じコンピューターを介したものですが、それ自体が盗まれた認証 Cookie であっても、それほど害を及ぼさないことも保証します。残高は表示されますが、何も転送できません。
于 2010-03-04T04:01:07.247 に答える
2

上記のほとんどのコメントに同意します。セキュリティが心配な場合は、次のことを行う必要があります-

a) 全体で https を使用します。最近、gmail でさえデフォルトで https を使用するように切り替えました - http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.htmlを参照してください

b) セッション Cookie にセキュア フラグを設定して、ブラウザーが HTTP 接続を介して送信しないようにします。

c) アプリケーションの XSS を修正します。xss の問題がある場合、'remember me' の実装は常に安全ではなくなります。OWASP XSS 防止チート シートを参照してください。

セッション識別子に IP アドレスを含めても役に立ちません。これを行うと、'remember me 機能' がほとんど役に立たなくなり、あまりセキュリティが追加されません。グーグルがセッション識別子にIPアドレスを入れていないことは確かです。

于 2010-03-04T03:14:57.170 に答える
1

完全に安全なサイトを作成する唯一の方法は、どこでもhttpsを有効にすることです。そうです、Cookieを盗聴し、後で偽装するために使用することができます。

于 2010-03-03T13:05:12.853 に答える
1

セッションを開いたクライアントのIPアドレスを保存するなど、セッションハイジャックを防ぐ方法はいくつかあります。自動ログイン機能がなくても、セッションを確認するには、追加のデータをサーバー側に保存する必要があります。攻撃者はハッシュされた値を指定して認証情報を見つけるために攻撃を仕掛ける可能性があるため、ハッシュされたユーザー名とパスワードではなく、トークンにナンスを使用する（または少なくとも非秘密データに基づく）方が適切です。

Facebook、Gmail、およびおそらく他のサイトのログインフォームのソースを見ると、ログインフォームアクションはHTTPSを使用しており、ログインが成功すると、セキュリティで保護されていないページにリダイレクトされます。

于 2010-03-03T13:22:29.730 に答える
1

1/ ユーザーが「remember me」をチェックすると: IP、ブラウザー、OS、言語など、彼のコンピューターに関するすべての情報のハッシュを保存し、このハッシュを彼の ID と共に彼の Cookie に書き込みます。戻って、彼の新しいハッシュを計算します。この値を、受信した Cookie の値、およびデータベースの値 (指定された ID について) と比較します。それらがすべて等しい場合、ユーザーを認証できます。

クリアですか？

XSS 攻撃がある場合、Https は何もできません (Cookie を盗む最善の方法)

于 2010-03-03T14:21:58.760 に答える