ユーザーの役割 - セッションに保存しない理由

Question

私はASP.NETアプリケーションをMVCに移植しており、ユーザーの表示内容を確認するために、ロールのリストと表示可能なアイテムIDのリストを含む、自動化されたユーザーに関する2つのアイテムを格納する必要があります。

Webサービスで過去にWSEを使用していたため、信じられないほど複雑になり、正しくデバッグすることができませんでした。今私は、セッションにこれらのものを格納するだけで、ソリューションを大幅に簡素化するために探していたWebサービスを捨てています。同僚は役割とメンバーシップ・プロバイダーの使用を提案しましたが、これを調べると多くの問題が見つかりました：

a）非常に制約の厳しい方法テストを書くことさえ厄介です。

b）RolesProviderの唯一のキャッシュオプションは、セキュリティ上の理由で拒否したCookieに基づいています。

c）合併症や不要な手荷物の終わりはありません。

簡単に言えば、ユーザーのセッションに2つの文字列変数などを安全に格納し、必要に応じてそれらを参照するだけです。何がそこにある私は思考を残してい

http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/

を参照して、10分のジョブは、これまでの調査の数日間を取ったし、我々は今、そのセッションIDは明らかに偽造することができます発見した問題点を配合することであると思われますこの簡単な仕事をする簡単な方法はありませんが、信じることは不可能です。

誰でした：

a）は、私はいつも彼らがいたと信じてASP.NET MVCセッションを安全にする方法についての簡単な情報を提供し？

b）上記のように複雑な悪夢を別の悪夢に置き換えることなく、ログインしたユーザの役割などのためにこれらの2つの文字列変数を保存する別の簡単な方法を提案しますか？

ありがとうございます。

Answer 1

セキュアな接続を確立する唯一の方法は、SSLを使用することです。それよりも少ないものであれば、「十分に安全」なときに評価を行うだけです。

セッション変数は、Webサーバーが現在リサイクルされている可能性があることを除いて、値を格納するのに問題ありません。セッションが失われる可能性があります。それが起こると、ユーザーを再認証してセッション変数を再度設定する必要があります。

セッション変数自体は、特にレスポンスにコピーしない限り、サーバーから離れないという意味で完全に安全です。

Answer 2

MVCでカスタムAuthorizeタグを設定することを検討しましたか。私は別の例でこれの例を与えたquestion。

初期認証（サインイン画面またはセッションの開始）時には、IPアドレスとともにセッション値をシードすることもできます。その後、カスタム認証では、IPがまだ一致していることを確認することもできます。これは、誰かがその人のセッションを盗んでいないことを確認するのに役立ちます。セッションデータにアクセスするたびに、リクエスタのIPを渡して確認してください。

Answer 3

クライアントレベルでの機能へのアクセスを制御しようとしていますか？これが、クライアント側の機能を制御する役割と項目を公開する唯一の理由です。

また、ユーザーのロールが使用できるアイテムを取得する関数を作成し、その関数がWebアプリケーションに戻されたアイテムの外部で呼び出された場合でも、そのユーザーを防ぐことができますそれらにアクセスすることから。

4Guysは、ロールを使用して機能を制御する方法を示しているようです。

Answer 4

私が過去に使用してきたアプローチは、SSLと並んでクッキーの対称暗号化を使用することです。応答内のユーザー情報を暗号化し、要求内で復号化します。私はこれが完全に安全か100％安全であると主張しているわけではありません。銀行アプリケーションでこれをやりたいとは思いませんが、多くの目的には十分です。

セッション変数の主な問題は、セッション変数を永続化するのではなく保存する場合、Webファーム環境で負荷分散に「固定」セッションを適用する必要があることです。 Guffaはこの永続性がなくてもセッション変数が失われてユーザエクスペリエンスが低下することは間違いないとしています。

スティッキセッションでは負荷分散が不均一になり、スケールアウトできる可能性が低下する可能性があります。

ウェブファーム内のすべてのサーバーからセッションにアクセスできるようにセッションを維持する場合は、Guidを使用してユーザーを識別し、Cookieでこれを暗号化し、ユーザーレコードを取得する方がよい場合があります毎回データストアから取得します。

Answer 5

私の明らかな疑問は、どうしてあなたはセッションでユーザーの役割を保存したいのですか？

これは私の質問に対する私の答えです。どのように役立ちますか。私はあなたのために、私のポイントを見て理解するための小さなデモアプリケーションを添付しています。このプロジェクトをVisual Studioで開くと、上部のプロジェクトタブをクリックし、asp.netの設定を選択します。表示されるページから、ユーザー管理作業を行うことができます。

ユーザーの役割を安全に保存する必要がありますか？この質問に対する答えは、asp.netのメンバシップ、プロファイル、ロールのフレームワークがあれば、ユーザーの役割を格納することを心配する必要はありません。 aspnetデータベースで役割を作成し、その役割をユーザーに割り当てるだけです。

次に、2つの文字列を安全な方法で保存します。ユーザー固有の情報を格納するためのユーザープロファイルをお勧めします。このようにして、profilecommonクラスから必要な情報を入手できます。

はまた私のブログサーバー側のセッションでは、ユーザーのロール情報を保存するhttp://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx

Answer 6

ハイジャックすることができないセッションを提供する安全であるの最後に置か添付のデモアプリケーションを参照してください。これをもっと広く言えば、認証されたセッションがハイジャックされた場合に、ユーザーのロール情報がどこに格納されるかは関係ありません。

リンク先の記事をあまり信頼していないことをお伝えしますが、あなたのリンクからリンクされた2002年のヴィンテージレポートが重要です。ここに私のテイクアウェイがあります：

1. URLに埋め込まれたセッションIDを受け入れないでください。

2. クロスサイトスクリプティングの危険性を排除すること、つまり、ユーザーが提供するすべてのデータをスキャンし、実行可能なJavaスクリプトを解析することに時間を集中します。完全なドメインの

3. 発行クッキー（例えばmyapp.mydomain.com）

4. は、例えばハイクラスのDNSオペレーターであなたのドメインをホストプリセットされたリモートIPアドレスからのDNS変更だけを許可するもの。

5. 永続セッションCookieを発行しないでください。

6. セッションIDがすでに認証済みセッションに関連付けられているログインページに誰かが到着した場合は、セッションクッキーを再発行します。

7. 成功した認証では常に新しいセッションCookieを発行し、以前のセッションを破棄します。 （これは、IISで設定することができますか？）

Answer 7

だけの提案、あなたはこの小さなライブラリを使用して検討するかもしれない：

http://www.codeproject.com/KB/aspnet/Univar.aspx

ことにより、すべてのクッキー缶それはクッキーのサーバー側の実装を持っていますasp.netの認証がユーザーを識別するために使用される間、サーバーに格納されます。暗号化をサポートしており、非常に柔軟性があり、あるストレージタイプから別のストレージタイプへの切り替えが非常に簡単です。