問題タブ [forms-authentication]

私たちの組織には、フォーム認証のための中心的なソリューションがあります。この外部 URL を使用する ASP.Net MVC アプリを実装しようとしていますが、RC までは機能していました。解放された...

これが何が起こっているかです

ActionAttribute 拡張機能内

見つからない場合はセッション変数をチェックし、見つかった場合はリクエスト データ チャックをチェックし、見つからない場合はセッション変数を設定します。見つかった場合は外部 URL にリダイレクトします。

問題は、RC1 に更新するまで、これが機能していたことです。それ以来、非常に多くのリクエストが外部 URL に送信されているため、DoS 攻撃を検出して私を締め出してしまいました!

リダイレクト コードを削除し、フォーム認証の web.config の変更に置き換えましたが、同じことが起こりました...

私は ASP.Net MVC を試してきましたが、特に MVC に関連していない問題に遭遇しました。しかし、デフォルトの MVC アプリケーション (新しい MVC プロジェクトを作成するときにウィザードによって作成されるアプリケーション) で認証を取得できず、Windows 7 上の IIS 7 で正しく機能しません。

Visual Studio 環境で実行すると動作しますが、代わりに IIS で実行するように設定を切り替えると、ログインまたは登録を送信しようとして次の例外が発生します。

ユーザーのローカル アプリケーション データ パスの取得に失敗したため、SQL Server のユーザー インスタンスを生成できませんでした。ユーザーがコンピューター上にローカル ユーザー プロファイルを持っていることを確認してください。接続が閉じられます。

これは、Web サイトが Visual Studio では自分のアカウントで実行されているのに、IIS では IUSR アカウントで実行されているためだと思います。例外メッセージに関する Google 検索は、これまでのところ役に立ちませんでした。

では、IUSR アカウントのローカル ユーザー プロファイルを作成できますか? もしそうなら、どのように？IIS 7 の匿名アカウントで SQLExpress エンジンを動作させるために他にすべきことはありますか?

私のアカウントを使用するように IIS Web サイトを構成しようとしましたが、これは私のホーム マシンであるため、私のアカウントにはパスワードがありません。または、これが IIS 7 の初めての経験であり、構成が IIS 5/6 とは大きく異なるため、匿名アクセスに使用するアカウントを構成できる適切な設定が欠けているだけです。

編集：いくつかの追加情報。App_Data フォルダーを空にして IIS から再試行すると、SQLExpress はデータベースの作成を試みて失敗しますが、例外メッセージには次の提案を含む詳細情報が含まれています。

SQLExpress データベース ファイルの自動作成 エラー:

接続文字列は、アプリケーションの App_Data ディレクトリ内のデータベースの場所を使用して、ローカルの Sql Server Express インスタンスを指定します。プロバイダーは、データベースが存在しないと判断したため、アプリケーション サービス データベースを自動的に作成しようとしました。アプリケーション サービス データベースの存在を正常に確認し、アプリケーション サービス データベースを自動的に作成するには、次の構成要件が必要です。

1. アプリケーションの App_Data ディレクトリがまだ存在しない場合、Web サーバー アカウントには、アプリケーション ディレクトリへの読み取りおよび書き込みアクセス権が必要です。App_Data ディレクトリがまだ存在しない場合、Web サーバー アカウントによって自動的に作成されるため、これが必要です。
2. アプリケーションの App_Data ディレクトリが既に存在する場合、Web サーバー アカウントには、アプリケーションの App_Data ディレクトリへの読み取りおよび書き込みアクセスのみが必要です。これが必要なのは、Web サーバー アカウントが Sql Server Express データベースがアプリケーションの App_Data ディレクトリ内に既に存在することを確認しようとするためです。Web サーバー アカウントから App_Data ディレクトリへの読み取りアクセスを取り消すと、プロバイダーは Sql Server Express データベースが既に存在するかどうかを正しく判断できなくなります。これにより、プロバイダーが既存のデータベースの複製を作成しようとすると、エラーが発生します。新しいデータベースの作成時に Web サーバー アカウントの資格情報が使用されるため、書き込みアクセスが必要です。
3. Sql Server Express がマシンにインストールされている必要があります。
4. Web サーバー アカウントのプロセス ID には、ローカル ユーザー プロファイルが必要です。マシン アカウントとドメイン アカウントの両方のローカル ユーザー プロファイルを作成する方法の詳細については、readme ドキュメントを参照してください。

最初の 3 つの提案が満たされていることをかなり広範囲に確認しました。4番目が私の問題の原因のようですが、その方法がわかりません。提案には、それを説明する readme ドキュメントがあると書かれていますが、私はそのドキュメントを見つけることができませんでした。

cookieless セッションを使用していて login.aspx の名前を httphandler に変更できない場合、無限ログイン ループの問題をどのように解決しますか?

つまり、管理者権限を持つユーザーがログアウト ボタンをクリックし、制限されたページへの戻り URL が login.aspx に渡されると、管理者権限を持たない別のユーザーがログインしようとすると、ログイン ページにリダイレクトされます。

私はこの解決策に出くわしましたが、login.aspx の名前を http ハンドラーに変更することはできません。フォーム認証チケットが URL から取り除かれているように見えるため、isauthenticated 関数は Cookie なしの認証を使用する aspx ページでは機能しないようです。ログインページにリダイレクトされたとき。

編集：

このアプリケーションは既に運用されているため、ログイン/ログアウト/タイムアウト プロセスのページ フローを変更したり、ログイン ページの名前を変更したりすることはできません。

form_authenticity_token はリクエストの検証に使用されるため、ユーザーがログインしているかどうかを既に確認している場合に使用するのは冗長ですか?

つまり、form_authenticity_token は、ログイン ユーザー専用のフォームではなく、誰でも使用できるフォームのみを対象としているのですか?

私は関連するセキュリティ リスクを知っており、それをビジネスに持ち出しましたが、5 つのドメインでログイン Cookie を共有したいと考えています。

ASP.Net メンバーシップとプロファイルを使用しており、使用をやめる予定はありません。これは可能ですか？ハックさえあれば大歓迎です。

一連の ASP.Net 2.0 .asmx Web サービスを保護しようとしています。Web サービスをホストする は、すでにフォーム認証されています。
フォーム認証を使用して Web サービスを保護することは可能ですか? これを達成するための長所と短所、およびその他の可能な方法は何ですか。確かに、各 Web メソッド呼び出しでユーザー名/パスワードまたはトークンを渡したくありません。

ハッシュ化されたパスワードタイプを使用するasp.netWebアプリ、フォーム認証があります。パスワードの種類を暗号化に変更した場合、問題が発生しますか？

暗号化に変更すると、古いハッシュパスワードのパスワード回復の試行が正常に失敗することがわかります。これは良いことです。私が変わると現れるかもしれないそれほど良くないものはありますか？

暗号化に変更した後に誰かがパスワードを変更した場合、パスワードの種類はハッシュのままになります。代わりに新しいパスワードを暗号化として保存するように強制する方法はありますか？

私の Web サイトは ASP.NET のフォーム認証を使用しており、認証チケット/Cookie の UserData 部分にユーザー固有の情報を挿入しています。UserData は認証チケット内にあるため、そのように暗号化されます

データは暗号化されているため、この時点でデータが危険にさらされる心配はありません。しかし、データがこのように暗号化されていない形式で利用できることに気付きました

データ自体はそれほど重要ではありません。他人に見られても大丈夫。しかし、人々がこの情報を乗っ取って自分のものとして使い始めることを許すことはできません。たとえば、あるユーザーが別のユーザーになりすましてログインすることは望ましくありません (UserData に含まれるユーザー ID に基づく)

これは私が心配しなければならないことですか？

編集1：

これを行う理由は、セッションの使用を停止し、Cookie と Ticket.UserData のみを使用できるようにするためです。

編集2：

Ticket.UserData のデータは変更されていません。ユーザーがログインすると一定になります。