8

ASP.NETフレームワーク（ASP.NET MVC、Webフォームなど）のいずれかでASP.NETフォーム認証を使用している場合、クライアントのブラウザーで認証Cookieを保持します。ベストプラクティスとして、CookieをHttpOnlyおよびsecureとして設定します。また、SSLを介してすべてのトランザクションを実行します。ユーザーの認証に使用するメカニズムの種類（OAuth、ASP.NETメンバーシッププロバイダーなど）に関係なく、ユーザーエクスペリエンスを向上させるには、認証を永続化する必要があります。

これらすべてが整っているので、誰かがクライアントブラウザからCookieを取得し、それらの認証Cookie値を使用してリクエストを発行できると想定しています。これはサーバーでは検出できず、保護されたデータを他の誰かに提供します。

ここでリスクを下げることを念頭に置いているのは、クライアントが深刻なアクション（電子メールアドレスの変更、プロファイル情報へのアクセスなど）を実行しようとするたびにクライアントのパスワードを尋ねることですが、これは解決しません。何でも、クライアントにとってかなり迷惑になる可能性があります。

この種の問題に対して積極的にフォローしているアプローチはありますか？または、クライアントブラウザで認証を永続化するための最良の方法は何でしょうか？

4

3 に答える 3

7

あなたは、一緒にいるためにほとんどすべてを正しくやっています。

メンバーシッププロバイダーを使用している場合、Cookieは（あなたが言ったように）HTTPのみとしてフラグが立てられるため、悪意のあるXSSなどのクライアントスクリプトを介してアクセスすることはできません。

Cookieに安全のフラグが設定されている場合は、フォーム認証の「RequireSSL」フラグをtrueに設定していると思います。これを行うことにより、HTTPSを介して送信されないサーバーへのリクエストでCookieが送信されないため、誤ってHTTPリクエストをスリップした場合でも（コンテンツが埋め込まれている場合は、ブラウザがユーザーに警告する必要があります） HTTPSページ）、Cookieは送信されません。

あなたができる他の唯一のこと-そしてこれはあなたが持っているものに加えて多くの防御を提供しませんが、それは良い習慣です-HSTSも使うことです。これについては、OWASP Top 10 for .NET開発者パート9：不十分なトランスポート層保護で、要求が安全なチャネルを介して送信され続けることを保証する追加の手段として説明します。

メンバーシッププロバイダーの本格的なリエンジニアリングに取り掛かる以外に、できることはそれほど多くありません。セッションをIPに関連付けて、変更された場合に要求を受け入れないようにすることもできますが、これにより問題が発生する可能性があります（つまり、IPが変更され、同じアドレス上の複数の人から保護されない）。ブラウザのフィンガープリント（つまり、リクエストヘッダーで送信されるすべてのもの）を作成し、後続のリクエストが一致することを確認することもできますが、ここでは非常に詳細に説明します。

ただし、最終的には、セキュリティは、保護している資産の価値と悪意のあるアクティビティの可能性に合わせて調整する必要があります。何を保護しているのかはわかりませんが、それが金融システムの場合は、ブログの単純なコメントエンジンの場合よりも長い時間を費やすことになります。

要約すると、あなたは素晴らしい仕事をしているように見えます。保護しているものの価値の文脈で、実行した対策の適切性を考慮してください。ああ-そして、クレデンシャルストレージにSQLメンバーシッププロバイダーを使用している場合は、パスワードハッシュに服がないことを確認してからそれをやめてください！

于 2012-08-03T09:30:16.360 に答える
2

あなたが行ったことすべてに余分なものを加え、この質問を念頭に置いて、認証Cookieと一緒にユーザーに関するより多くの情報をサーバーに保持することをお勧めします。したがって、誰かがCookieを盗んで使用しようとした場合も、それを使用できるようにするには、クライアントの残りのすべての特性を満たす必要があります。

私が保持して確認している残りの情報のいくつかは、認証Cookieと同じであるということです。

  1. 認証Cookieに接続されたセッションCookie。
  2. 接続されているブラウザID
  3. ユーザーのIPはに接続されています
  4. Javascriptを有効にする必要があります

私は、ハッカーがすべてのクローンを作成できると言う人がいることを知っています。ハッカーがCookieを取得できるのであれば、なぜ取得できないのか、残りの部分は取得できません。シナリオでは100％保証されるものはなく、誰かが実際に持つことができるすべての情報とパスワードを自分で取得してログインできる場合は、少なくとももう少し安全になります。

于 2012-08-03T09:24:53.197 に答える
1

すでにHTTPSを使用しており、Cookieを暗号化しています。これはかなり安全です。

それでも心配な場合は、ユーザーのセッションに関する追加情報（IPアドレス、ユーザーエージェントなど）をサーバーに保存し、セッション中に提供された情報と照合して確認することをお勧めします。

ユーザーが自分の電子メールアドレスを変更した場合、元の電子メールアドレスへの取り消しリンクを送信できます。そのため、その変更が許可されていない場合、真の所有者に変更が通知されます。

于 2012-08-03T09:21:38.840 に答える