8

私は、セッション変数を使用してユーザーを追跡するアプリケーションに取り組んでおり、マスターページでその存在を確認し、それ以外の場合はユーザーをノックアウトしてログインさせます。これをフォーム認証に変更したかったのは、より安全でデータが暗号化されていると読んだからです。

実際に暗号化されているデータを誰か教えてもらえますか? サイトでフォーム認証を設定しようとしましたが、正常に動作し、ユーザーは適切に追跡されており、ログインせずにページにアクセスすることはできません。ただし、Fiddler を使用してリクエスト本文を見ると、すべてのフォーム フィールドが表示されます。コンテンツ。セッション変数から生成された Cookie の場合のように、ハッカーはそれを使用してデータを変更し、リクエストを再送信できませんか? このアプリケーションは SSL を使用していないので、SSL が本文を暗号化することは理解していますが、それはフォーム認証でも行われることだと思いました。それ以外の場合は、Cookie のセッション ID だけで何を暗号化しますか?

これが私が使用していたコードです：

    <authentication mode="Forms">
  <forms loginUrl="default.aspx" name=".ASPXFORMSAUTH_Test" defaultUrl="home.aspx" protection="All"/>
</authentication>
<authorization>
  <deny users="?"/>
</authorization>

ログインページで、Cookieを手動で作成しようとしました:

                    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
                    txtEmail.Text,
                    DateTime.Now,
                    DateTime.Now.AddMinutes(30),
                    false,
                    txtEmail.Text,
                    FormsAuthentication.FormsCookiePath);

                // Encrypt the ticket.
                string encTicket = FormsAuthentication.Encrypt(ticket);

                // Create the cookie.
                Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket));

                // Redirect back to original URL.
                Response.Redirect(FormsAuthentication.GetRedirectUrl(txtEmail.Text, false));

私も試しました：

FormsAuthentication.RedirectFromLoginPage(txtEmail.Text, false);

以前、同じ結果が得られました。Fiddler のリクエスト本文には、送信されたすべてのフィールドとその内容が表示されます。

4

3 に答える 3

2

アプローチをフォーム認証に切り替えても、セキュリティが向上するわけではありません。これは、より標準化された認証メカニズムを使用して、認証関連の問題についてソフトウェアを監査しやすくすることを意味します。

また、FormsAuthentication は通常、ユーザーのセッションが期限切れになった場合 (またはアプリケーション プールがリサイクルされた場合) にも機能します。これは、独自の有効期限ポリシーを使用して暗号化された Cookie にユーザー データを格納するためです。

于 2013-05-14T15:23:48.697 に答える
1

SSL を使用せずに、ユーザー資格情報やその他の機密データを処理しないでください。

SSL を使用するかどうかに関係なく、投稿されたデータは常にクライアントから表示され、常に「偽造」される可能性があります。SSL は (適切に使用されれば) 通信を傍受する「中間者」から保護できますが、厳密に実装されていなければほとんど役に立たないことを認識することが重要です。したがって、Strict Transportの使用も検討する必要があります。すべてのブラウザーでサポートされていない場合でも、セキュリティ。

セッション ID は「暗号化」されていませんが、(実際には) セッション ID を「推測」することはできません。HTTP(S) はステートレスであり、特定のクライアントからのリクエスト自体が悪意があるかどうかを判断する方法はありません。すべてのリクエストは、暗号化されているかどうかにかかわらず、クライアントからのすべての Cookie を保持します (もちろん、Cookie 内のデータが暗号化されている場合、その内容を偽造することは困難です)。

できることとすべきことは、XSS や CSRF 攻撃などの影響を受けて、Cookie が適切なコンテキストをエスケープしないようにすることです。FormsAuthentication は、デフォルトで Cookie にのみ HTTP を使用します。Web 上のすべての Cookie が HTTP のみであることを確認するには、web.config に次のように記述します。

<httpCookies httpOnlyCookies="true" />

すべての Cookie が安全な接続にバインドされるようにするには、次を使用します。

<httpCookies requireSSL="true" />

ここで、フォーム認証よりも前にフォーム認証を使用する主な理由は、それが実績のあるソリューションだからです。壊れた認証とセッション管理は、OWASP トップ 10で 2 位にランクされています。これは、正しく行うのが思ったよりも難しいためです。

フォーム認証には、非常に構成可能であり、ストア内のユーザー資格情報を適切に暗号化するという利点もあります (そうするように指示した場合)。標準的な実装は、最新の GPU ベースのブルート フォースの可能性に照らして決して防弾ではありませんが、少なくとも間違った方法では実行されていません。

標準実装がどのように機能するかについて詳しく知りたい場合は、自由に利用できる逆コンパイラを使用できます。

于 2013-05-14T15:46:22.650 に答える
1

フォーム認証は、FormsAuthentication オブジェクトを使用して、ユーザーの Cookie を設定します。クッキーには、ユーザーの識別情報が含まれています。HTTP のみの Cookie はクライアントではなくサーバーでのみ使用できるため、その Cookie が HTTP のみであるかどうかはわかりません。これらの Cookie はサーバー上で復号化され、ユーザー ID などを取得します。

したがって、それが HTTP のみの Cookie でない場合、問題になる可能性があります。ただし、情報は暗号化されているため、ユーザーは暗号化を解除して基になるキーを知る必要があります。セッション 実際の情報ではなく、セッション ID のみが安全に追跡されていると思いました。ユーザーの情報は引き続きサーバーに保存されます。

最後に、最近人々が言及する最初の最も重要な防御は SSL です。私が見つけたものから、10ドルほどで証明書を取得できます...

于 2013-05-14T14:44:35.690 に答える