11

アップデート

最終的に、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分のタイムアウトを使用することをお勧めしますが、これはアプリケーションのタイプと予想される使用法に大きく依存します。
4

1 に答える 1

10

私が覚えているように、ASP.NETセッションIDジェネレーターは、セッション予測に対して優れた保護を提供します。セッションIDは、[az]文字と[0-5]桁を使用する24文字（2 ^ 5である32の可能な文字の合計）を持ち、合計2 ^（5 * 24）= 2^120の可能な値を与えます。ただし、SessionIDManagerを実装して、保護をさらに強化するためにいくつかの情報（ユーザーホストアドレス、ユーザーエージェント、HMACアルゴリズムを使用する検証トークンなど）を追加することができます。これにより、別のIPアドレスまたは別のブラウザーからのセッションIDが渡されなくなります。検証。フォーム認証を実装している場合、認証チケットはすでにこれらの種類の保護を提供しているため、これは必要ありません。

より適切なランダムセッションIDが必要な場合は、SessionIDManagerでRNGCryptoServiceProviderなどのRandomNumberGeneratorを使用し、一連のバイト（たとえば、256ビットである32）を入力してから、Base64を使用してエンコードします。

byte[] random = new byte[100];
//RNGCryptoServiceProvider is an implementation of a random number generator.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
rng.GetBytes(random); // The array is now filled with cryptographically strong random bytes.
return Convert.ToBase64String(random)

ただし、この記事では、セッションIDの最大長は80であると述べているため、それを機能させるには、Validateメソッドもオーバーライドする必要があります。

于 2011-08-01T18:33:38.527 に答える