3

シナリオ

  1. サーバーとブラウザを再起動して、セッションデータがないようにします。
  2. www.someurl.comのパブリックアクセスページにアクセスします。私のコントローラーは私にこれとのセッションを取得しますHttpSession session=request.getSession(true);
  3. 新しいタブで開くwww.someurl.com/admin制限付きアクセスページへのプレーンアンカーリンクをクリックします。Spring Security 3はこれを傍受し、資格情報を要求します。正常にログインしました。
  4. www.someurl.comで前のタブに戻り、ページを更新します。

問題

www.someurl.comのコントローラーで気付いたのは、ステップ2とステップ4でセッションIDが異なることです。SpringSecurityが新しいセッションを作成し、そのセッションがパブリックページのリクエストにアタッチされているようです。なぜこれが発生し、Spring Securityに既存のセッションを使用させることができますか？

トレースされたシナリオ

  1. ブラウザとサーバーを再起動して、セッションデータが存在しないようにします。
  2. www.someurl.comにアクセスします。コントローラにリクエストが挿入されました。request.sessionがnullです。getSession（true）は、ID87B091B12F38D44C53AF0DA9E2147484のセッションを取得します。LogServiceはリクエストオブジェクトを取得し、getSession（true）も取得しますが、ID 87B091B12F38D44C53AF0DA9E2147484のセッションを取得するため、これまでのところすべて問題ありません。
  3. /adminをクリックします。ページが新しいタブで開きます。ログインします。
  4. www.someurl.comを更新します。コントローラにリクエストが挿入されました。request.sessionはnullではありません。セッションIDは547DF59035C91783D783BAEF4A15FBFFです。
4

2 に答える 2

11

あなたはあなたの診断を間違えました：

www.someurl.comのコントローラーで気付いたのは、ステップ2とステップ4でセッションIDが異なることです。SpringSecurityが新しいセッションを作成し、そのセッションがパブリックページのリクエストにアタッチされているようです。

すべてのページが同じセッションを使用しているため、最初のタブに戻って更新しても、管理者としてログインしたままになります。特定のブラウザのすべてのタブとフレームは、特定のWebアプリの同じセッションを共有します。それがどのように機能するかです。サーバーはブラウザのタブを認識せず、気にしません。特定のブラウザから送信されたすべてのリクエストに添付されたセッションCookieを取得し、このCookieを使用して対応するセッションを取得します。これは実際には良いことです。それがないと、認証済みの新しいタブを開くたびに、再度認証する必要があります。そして、あなたは間違いなくそれを望んでいません。

それでは、シナリオで何が起こるかを説明しましょう。

  1. サーバーとブラウザを再起動して、セッションデータがないようにします。
  2. www.someurl.comパブリックアクセスページにアクセスします。コントローラがセッションを取得します。Cookieがブラウザに返送されます
  3. 新しいタブで開くwww.someurl.com/admin制限付きアクセスページへのプレーンアンカーリンクをクリックします。Cookieはリクエストとともに送信されるため、このリクエストはステップ2で開かれたセッションの一部です。SpringSecurity3はこれを傍受し、資格情報を要求します。これは、認証されたセッションであるセッションに資格情報を添付します
  4. www.someurl.comで前のタブに戻り、ページを更新します。Cookieが再度送信され、認証資格情報がセッションに保存されるため、Springはあなたがステップ3で認証した人であることを認識します。

編集：私が間違っていたようです。Springは、セッション固定攻撃を防ぐために、ログイン後に実際に新しいセッションを作成します。これが役立つ理由と、この動作を回避する方法についての説明は、ドキュメントに記載されています。

セッション固定攻撃は、悪意のある攻撃者がサイトにアクセスしてセッションを作成し、別のユーザーに同じセッションでログインするように誘導する可能性がある潜在的なリスクです（パラメータとしてセッション識別子を含むリンクを送信することにより、例）。Spring Securityは、ユーザーがログインしたときに新しいセッションを作成することで、これを自動的に保護します。この保護が不要な場合、または他の要件と競合する場合は、のsession-fixation-protection属性を使用して動作を制御できます。 3つのオプションがあります

  • mergeSession-新しいセッションを作成し、既存のセッション属性を新しいセッションにコピーします。これがデフォルトです。

  • none-何もしないでください。元のセッションは保持されます。

  • newSession-既存のセッションデータをコピーせずに、新しい「クリーンな」セッションを作成します。

于 2013-01-05T22:08:58.080 に答える
3

HttpSessionRequestCacheセッションが存在しない場合にセッションが作成されないように、の動作を変更する必要があります。

これを行うには、次のようにXML構成でインスタンスを作成します。

<beans:bean id="httpSessionRequestCache" class="org.springframework.security.web.savedrequest.HttpSessionRequestCache"> 
    <beans:property name="createSessionAllowed" value="false" /> 
</beans:bean>

次に、Beanインスタンスを使用するようにSpringセキュリティ構成でhttp要素を構成する必要があります。

<http auto-config="true" ....> 
    <request-cache ref="httpSessionRequestCache"/> 
    ... rest of your config
</http>

JSPを使用している場合は、JSPがセッションを作成しないようにする必要もあります。これを行うには、すべてのJSP（他のJSPから含まれているものも含む）のpage上にディレクティブを追加する必要があります。

<%@ page session="false" %>
于 2013-01-05T23:40:10.470 に答える