login.aspxとsecret.aspxの2ページしかない単純なサイトがあるとします。サイトは、ASP.netフォーム認証とlogin.aspxのASP.netログインサーバーコントロールのみを使用して保護されます。詳細は以下のとおりです。
明らかにセキュリティに関して考慮すべきことがたくさんありますが、私は.netフレームワークに付属するゼロコードのアウトオブボックスエクスペリエンスにもっと興味があります。
この質問のために、login.aspxのユーザー名/パスワードテキストボックスのみが攻撃ポイントである場合、ハッカーは、secret.aspxページにアクセスできるようにするコードを挿入できますか？
マイクロソフトが提供するゼロコードのアウトオブボックスエクスペリエンスはどの程度安全ですか？
考慮されていない変数がまだいくつかあります。
これらの問題のすべてが MS 固有であるとは限りませんが、対処しないと、質問している問題を簡単に上回る可能性があるため、言及する価値があります。しかし、あなたの質問の目的のために、私はそれらに何の問題もないと仮定します.
その場合、フォーム認証が本来の機能を果たしていると確信しています。現在アクティブなエクスプロイトはないと思います。
私の知る限り、パスワードはプレーンテキスト（ただしエンコードされたもの）として送信されます。したがって、最も重要なことは、ログイン画面でHTTPSプロトコルを使用することです。
他の設定は私にとって安全なようです。
.NET 基本フォーム認証で使用されている HTTP 基本認証では、secret.aspx ページを表示するために、ブラウザはユーザー名とパスワードの Base64 エンコード連結を送信する必要があります。
SSL を使用しない限り、サーバーとブラウザの間のネットワークをスキャンするアクセス権を持つ人なら誰でもこの情報を読み取ることができます。ユーザー名とパスワードを解読できます。今後、ユーザー名とパスワードを再生して、secret.aspx ページにアクセスできます。
とはいえ、SSL を使用しない限り、誰かが secret.aspx を使用して他の誰かのセッション全体をスキャンすることもできるため、事実上、彼らはページのコンテンツにもアクセスできます。
さて、舞台裏を見てみてください：
パスワード保護
ユーザー名、パスワード、およびその他の認証情報をデータベースに保存するアプリケーションは、データベースが盗まれたり危険にさらされたりしないように、パスワードをプレーンテキストで保存しないでください。そのために、SqlMembershipProviderは、パスワードとパスワード回答の3つのストレージ形式（「エンコーディング」）をサポートしています。passwordFormat構成属性から初期化されるプロバイダーのPasswordFormatプロパティは、使用される形式を決定します。
- MembershipPasswordFormat.Clearは、パスワードとパスワードの回答をプレーンテキストで保存します。
- MembershipPasswordFormat.Hashed（デフォルト）。パスワードとパスワード回答から生成されたソルトハッシュを格納します。ソルトは、.NETFrameworkのRNGCryptoServiceProviderクラスによって生成されるランダムな128ビット値です。パスワードとパスワードの回答の各ペアは、この一意の値でソルトされ、ソルトはaspnet_MembershipテーブルのPasswordSaltフィールドに格納されます。パスワードとソルトをハッシュした結果は、[パスワード]フィールドに保存されます。同様に、パスワードの回答とソルトをハッシュした結果は、PasswordAnswerフィールドに保存されます。
- MembershipPasswordFormat.Encryptedは、暗号化されたパスワードとパスワードの回答を格納します。SqlMembershipProviderは、構成セクションのdecryptionKey属性で指定された対称暗号化/復号化キーと、構成セクションの復号化属性で指定された暗号化アルゴリズムを使用して、パスワードとパスワード回答を暗号化します。SqlMembershipProviderは、パスワードとパスワードの回答を暗号化するように求められた場合、およびdecryptionKeyが自動生成に設定されている場合に例外をスローします。これにより、暗号化されたパスワードとパスワードの回答を含むメンバーシップデータベースが、別のサーバーまたは別のアプリケーションに移動された場合に無効になるのを防ぎます。
したがって、（箱から出して）セキュリティの強さは、使用しているパスワード保護形式の戦略によって異なります。
ある種のレインボーテーブルハックをデフォルトのハッシュベースシステムに使用できるかどうかはわかりません。
詳細については、次のリンクを確認してください：http: //msdn.microsoft.com/en-us/library/aa478949.aspx
メンバーシップ プロバイダーを介して正しく構成されていれば、適切なレベルのセキュリティが得られます。それ以外では、そのページへのアクセスは正規の攻撃によってアクセス可能になる可能性がありますが、それは一般的なセキュリティに関係しています. Security Enterprise Application Blocksの使用に関するプレゼンテーションを行いました。サイトにセキュリティを実装する際には、それらを読み、それを調べて、一般的なセキュリティの脅威に注意することをお勧めします。あなたがオープンな共有ネットワーク上にいて、完全なセキュリティが軍によって24時間年中無休で守られた金庫にロックされたプラグを抜いたサーバーであることを考えると、100％ハッキングされないサイトはありません（オレンジブックに基づく国防総省の「A」レベルのセキュリティ程度） ）。ただし、メンバーシップ プロバイダーのすぐに使える機能 (正しく構成されている場合) は、十分なセキュリティを提供します。
編集: ええ、他のコメントに同意します。パケット スニファーやネットワーク モニターからユーザー名/パスワードを保護する場合は、少なくともログイン画面で HTTPS を使用する必要があります。
URLを介したCookieは十分に安全ではなく、URLに関するさまざまな問題（特に、もしあればリファラーの漏洩）とHTTPSの使用法があります。
この件に関する Microsoft の 2 つの優れた記事を次に示します。
このブログ投稿が示すように、Asp.Net は Cookie を使用しないセッションをサポートしています。セッション Cookie の代わりに、URL の識別子を使用してユーザーを追跡します。
これがどれほど安全かはわかりませんが、ID文字列を力ずくで攻撃するのが難しいため、安全だと思います。
多かれ少なかれそのままで動作するように見えますが、ユーザーをリダイレクトしてセッション状態を維持したい場合は、セッション ID を含める必要があります。ブログの投稿では、その方法と Web 上の他の多くの記事が示されています。