問題タブ [asp.net-session]

シナリオ: Silverlight (4) で開発された PRISM アプリケーションがあり、ASP.NET サーバー側アプリケーションを使用して複数の Web サービスをホストしています (Web サービスは WCF サービスにアクセスしますが、ここではそれほど重要ではありません)。 ）。Silverlight アプリケーションは、Web サービスをクロスドメインで呼び出すことができる必要があります (つまり、Web サービスは Silverlight アプリケーションをホストしている同じサーバー上にあるとは限りません)。

Silverlight アプリケーションはいくつかのモジュールで構成され、それぞれが ASP.NET Web サービスにアクセスします。

私は Silverlight と PRISM の経験があまりありませんが、私が見る限り、これは非常に珍しいシナリオではありません...

問題: 私の課題は、2 つの異なるモジュールが Web サービスにアクセスすると、Web サーバーで 2 つの新しいセッションを取得することです。両方のモジュールが同じ HTML ページ上 (そして同じブラウザー セッション内) にあるため、Web サーバー上で同じセッションを取得すると思いました...?

インスタンスを登録し（Container.RegisterInstanceを使用）、モジュールがWebサービス呼び出しを行う必要があるたびにこのインスタンスを取得することにより、（Unityを使用して）コンテナでWebサービスProxy-clientをグローバルに利用できるようにしようとしました（ Container.Resolve を使用しています)、しかしこれは役に立たないようです。

ただし、同じモジュール内で行われた呼び出しは、常にサーバー上で同じセッションを取得します。

ここで私が見逃しているものを見ることができますか...？

ありがとう！

ジョン

私の問題は、別の IE ウィンドウで Outlook から Web アプリケーションを開くと、ASP.NET セッションが失われることです。これは (いくつかの場所で説明されているように) メモリ内 Cookie が失われるためです。

したがって、次のようになります。

1. ユーザーが Outlook で ASP.NET Web アプリケーションを操作すると、ASP.NET セッションにいくつかの情報が保存されます
2. ユーザーが [印刷] をクリックして、印刷可能なデータを含む新しい IE ウィンドウを開く
3. 新しいウィンドウには異なる ASP.NET セッション ID があり、古いデータにアクセスできません。

おそらく、ASP.NET セッション ID を新しい IE ウィンドウに渡せば、どうにかしてそのセッションに「アタッチ」できますか? これが最新である必要があることを ASP.NET に伝えますか?

私が知る限り、現在の状況は次のとおりです。

1. SQL セッション状態プロバイダーを使用することは可能ですが (どこかで読んだことがあります)、Microsoft ではサポートされていません。そのため、今後機能しなくなる可能性があります。また、古いデータを削除するには WorkerRole が必要です。
2. Azure AppFabric Caching Service はまだ CTP にあります。
3. TableStorageSessionProvider は、運用コードには推奨されない Azure トレーニング キットのコードの一部です。

あなたなら何を選びますか？

Azure トレーニング キットの TableStorageSessionStateProvider を使用しようとしています。この例は問題なく使用できますが、Web アプリで使用すると、次の例外が発生します。

これを試してみましたが、これまでのところ運がありません.null参照例外が発生しているのも見たので、TableStorageSessionStateProviderがInProcのように動作していないと思うので、アプリケーションでセッションがどのように使用されているかを確認する必要があるかもしれません. しかし、何が問題なのでしょうか?

編集:まあ、同じ例外で TableStorageSessionStateProvider のみを使用すると、Azure トレーニング キットの例も失敗することがわかりました。他のプロバイダーにコメントするだけです:

私のアプリケーションには、Login.aspx と Home.aspx の 2 つのページがあります。

ユーザーがログインしていない場合、Web ブラウザーから Home.aspx にアクセスしてはなりません。

セッションでそれが可能であることは知っていますが、同じことを実装する方法がわかりません。

その方法を教えてください。

ありがとう！

別のプログラマーを開始したプロジェクトを終了しています。アーキテクチャ全体を変更することはできませんが、いくつか上書きしたいことがあります。つまり、承認、および現在のユーザーセッションを保存する方法です。プロジェクトは、soap サービスを介してサーバーと通信するクライアントを表します。サーバーには、Security-Services と、A サービス、B サービスなどのいくつかのサービスがあります。セキュリティ サービスは、他のサービスを初期化するための認証とセッション キーを提供します。このプロジェクトは ASP.NET MVC3 で記述されています。これはユーザー モデルのヘッドであり、サービスと対話する方法を記述したシングルトーン クラスとして実装されています。承認のしくみ - オーバーライドされた ValidateUser メソッドを持つ CustomMembershipProvider があり、Security-service で動作します。

主な問題は、セッションがメモリに保存されるようになったことです: web.config:

Set SqlServer-mode は、SiteUser のシリアル化が困難になるため問題があります。どうすればこれを回避できますか? また、認証に問題があります - サービスのセッションで Asp.Net 同期セッションを正しく行うにはどうすればよいですか? 説明が必要な場合は、私の英語で申し訳ありません-質問してください。ありがとうございました。

編集

この問題は奇妙に消えたようです。私の環境には何かファンキーなものがあったに違いありません。この質問を閉じるために投票します。

ユーザーがログインすると、ログイン ページのコード ビハインドからの一連のデータでセッションを膨らませます。次に、ユーザーをアプリケーションの別のページにリダイレクトします。また、ユーザーのセッションが期限切れになったときに、認証チケットに基づいてセッションを再膨張させるセッション回復ロジックもいくつかあります。

起こっているように見えるのは、ログインページからの一連のデータでユーザーのセッションを膨らませてからリダイレクトし、リダイレクト先のページのリクエストにセッションがないように見えるため、アプリケーションには再び膨らませます。これがわかりません。Cookie を確認しましたが、セッション ID が変更されておらず、コードのどこにもセッション データがリセットされていません。これは ASP .NET の「機能」ですか? ASP .NET 4.0 を使用しています。

編集：

明確にするために：セッションは、ログインリクエスト中に（ログインボタンのクリックでも）膨張します。次のリクエストでは、セッションにデータが取り込まれているようには見えないため、最終的にセッションを再拡張する必要があります。その後、ユーザーが行うリクエストはすべて、セッションが「固定」されているように見え、後続のリクエストに対して適切に膨らんだセッションがあります。

asp.netを使用しており、SQLサーバーに格納するようにセッションを構成しました。私のオブジェクトには、多くのオブジェクトといくつかのlinq-to-sqldbmlがあります。それらすべてを単方向シリアル化するように構成し、いくつかのカスタマイズされた変更も行いました。

アプリを実行すると、application_errorイベントハンドラーでこのエラーが発生し続けます

アセンブリ'App_Code.thzd8p2j、Version = 0.0.0.0、Culture = neutral、PublicKeyToken =null'に'Data.Karaoke.spCWP_SelUserPrivilegesResult'と入力すると、シリアル化可能としてマークされません。

エラーから、これがコードであるdbml.designer.csファイルからのものかどうかはわかりません。

と

エラーの原因を特定するにはどうすればよいですか？または、エラーはどういう意味ですか？

問題を解決する方法や、問題を解決するために何を探すべきかわからない。

私は 2 つの URl を持っています。最初の URL を開くと、認証が許可されます。2 番目の URL は、Web コンテンツを XML データとして開きます。そのデータを読み取る必要があります...しかし、最初のURLを実行すると、認証は正常に機能しますが、すぐに2番目のURLを開こうとすると、 Authentication failed と表示されます。最初の URL から 2 番目の URL へのセッションを維持する方法...

私のコード：

アップデート

最終的に、Acunetixチームの一部のプログラマーとミーティングを行いました。彼らは、コードにいくつかのバグがあり、実際よりも多くの問題としてスキャンに表示される原因になっている可能性があることに気付きました。一般的なコンセンサスは、スキャン結果を無視し、すぐに使用できるASP.NETセッションIDの生成を使用することでした。これは、サイトにとって十分に安全である必要があるためです。

@Vasile Bujacはあなたの答えが唯一のものであり、ASP.NET標準ソリューションを使用して言及したので、私はそれを答えとして取り上げましたが、皆さんの助けに感謝します。

AcunetixのRetinaスキャナーを使用して、アプリケーションのセキュリティスキャンを実行します。これは、セッションIDが十分にランダムではなく、予測しすぎることを示しています。ASP.NETがデフォルトでセッションIDを生成する方法は正確にはわかりませんが（とにかくGUIDだと思いましたか？）、先に進んで、SessionIDManagerクラスを拡張し、CreateSessionIDメソッドとValidateメソッドをオーバーライドしてGUIDを使用するメソッドを実装しました。このMSDNの記事で説明されているように。

これにより少しランダムになりますが、Acunetixによると「望ましい」効果はまだ得られていません。regenerateExpiredSessionId="true"プロパティをweb.configに追加しましたが、効果はありませんでした。Session.Abandon()セッションを本当にクリアして新しいIDを取得するには、意図的に電話をかける必要があるかもしれないと感じています。問題は、ユーザーが新しいセッションを開始していることを知る唯一のフェイルプルーフの方法であるため、ユーザーがログインする直前に呼び出す必要があることです。そのため、メソッドが機能する方法で次のページが読み込まれるまで、セッションで何も設定できませんでした。つまり、Abandon中間ページはあまり理想的ではありませんが、うまくいくでしょう。

誰かがこれを経験したか、修正を正常に実装したことがありますか？

また、参考までに、メンバーシップ/フォーム認証は使用しません。誰かがログインしたときに新しいカスタムユーザークラスを作成し、後で使用できるようにセッションに保存します。

Acunetixからのレポート：

CWE-330 CAPEC-59 OWASP2007-A7

説明： 低エントロピー（「ランダム性」）を示すセッショントークンは、多くの場合、予測攻撃の影響を受けやすくなっています。安全でないトークンは、不適切な疑似乱数ジェネレーター、時間ベースの値、静的な値、またはユーザー属性（ユーザー名またはユーザーID）に基づく値が原因である可能性があります。これは、攻撃者がアプリケーションを短期間監視し、作成したセッショントークンを収集した後、有効なセッショントークンを推測できることを意味します。攻撃者が別のユーザーの有効なセッショントークンを決定した場合、被害者のユーザー名やパスワードを推測することなく、任意のユーザーのデータを表示、変更、または削除できる可能性があります。その結果、有効なセッショントークンを推測する機能により、攻撃者はログインページをバイパスし、ブルートフォースアカウントを不要にすることができます。さらに、静的トークンを使用すると、被害者が現在アプリケーションにログインしていない場合でも、攻撃者がユーザーを標的にすることができます。これにより、攻撃者が標的にできる被害者のプールが増えます。

セッショントークンは、強力な乱数ジェネレーターを使用して作成し、多数の数値プールから収集する必要があります。たとえば、オペレーティングシステムのrand（）関数は、統計的に均一な分布である32ビット値を生成できる場合は通常は十分です。貧弱なセッショントークンは増分的であり、ユーザーのアカウントIDに依存し、タイムスタンプのみを使用するか、またはその他の非常に決定論的な情報を持っています。セッショントークンのセキュリティを保護する他の方法は、常にSSLを介してそれらを送信し、一定期間後にトークンを自動的に期限切れにし、ユーザーがアプリケーションからログアウトするたびにトークンを明示的に期限切れにすることです。

推奨事項：セッション値が強いランダム性を示しているが、値の小さなプールから選択されている場合、攻撃者は単に有効なトークンを推測する可能性が高くなります。Webアプリケーションのセッション管理は、いくつかの補完的な手法を実装することで改善できます。

• トークン値のサイズが少なくとも32ビットであることを確認してください。特に、同時ユーザー数が多く、毎日のページ要求が多いアプリケーションの場合はそうです。
• エントロピーのソースのビットサイズ（ランダムな値）は、実際のセッショントークンのビットサイズよりも重要です。たとえば、MD5ハッシュは128ビット値を生成します。ただし、増分値のMD5ハッシュ、タイムスタンプ、または8ビットの乱数は、ランダム値のソースを簡単に予測できるため、それぞれ安全ではありません。したがって、128ビットサイズはセッショントークンの正確な測定値を表していません。エントロピーソースの最小サイズは32ビットですが、1時間あたりの同時ユーザー数が10,000を超えるサイトでは、より大きなプール（48ビットまたは64ビット）が必要になる場合があります。
• ほとんどの場合、アプリケーションで生成されたトークン（ASP.NET_SessionId、ASPSESSIONID、JSPSESSIONID、PHPSESSIONIDなど）は、セッション予測攻撃を防ぐのに十分な大きさのランダムな値を提供します。カスタムセッションメカニズムが徹底的にレビューおよびテストされていない限り、アプリケーションはこれらのセッション管理アルゴリズムを使用する必要があります。
• ユーザーのなりすまし攻撃を防ぐために、サーバー側オブジェクトを使用してセッショントークンに関連付けられたユーザー属性を追跡します。アプリケーションがユーザーのセッショントークンをそのユーザーのプロファイル情報に厳密に関連付けていない場合、攻撃者はクライアント側の値を操作することで任意の情報を表示できる可能性があります。たとえば、アプリケーションが強力なセッショントークンを設定しているが、「UserId」Cookieに基づいてSQLクエリを実行する場合、攻撃者は「UserId」Cookieを変更するだけで他の誰かになりすますことができます。攻撃者は値を変更できないため、アプリケーションが「UserId」値をサーバー側のセッションオブジェクトに関連付けた場合、アプリケーションはより安全になります。
• ユーザーがアプリケーションからログアウトしたとき、または所定の非アクティブ期間が経過した後、セッショントークンを期限切れにします。セッショントークンには20分のタイムアウトを使用することをお勧めしますが、これはアプリケーションのタイプと予想される使用法に大きく依存します。