CODEWITHSUNDEEP
springspring-security
Akash.
Akash.

Reputation: 19

Spring Security session-management session-fixation-protection not working

I am using Spring 3.1 Security. Following is the part of my "spring-security.xml"

<session-management session-fixation-protection="migrateSession">
<concurrency-control max-sessions="1" expired-url="/Login.html"/>
</session-management>

Though I set session-fixation-protection="migrateSession" still if I logged in using "Chrome Browser" then copy cookie value and open a "Firefox Browser" and go to the login page then edit the cookie and paste value from "Chrome Browser", then I see that I am logged in into my application. That means "session fixation attack" is possible !!!

Did I miss anything in my spring security config ?

It's just my following cofig file

<http auto-config="false" access-denied-page="/" disable-url-rewriting="true">

<intercept-url pattern="/test01*" access="ROLE_USER" requires-channel="https"/>
<intercept-url pattern="/test02*" access="ROLE_USER" requires-channel="https"/>

<form-login login-page="/Login.html"/>
<logout invalidate-session="true"
        logout-success-url="/"
        logout-url="/logout"/>


<session-management session-fixation-protection="migrateSession">        
    <concurrency-control max-sessions="1" expired-url="/Login.html"/>
</session-management>

</http>

<authentication-manager>
<authentication-provider>
<user-service>    
<user name="a" password="a" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>

Upvotes: 1

Views: 17875

Answers (2)

Nandkumar Tekale
Nandkumar Tekale

Reputation: 16158

It is beacause you supplied, session-fixation-protection="migrateSession". That is session from Chrome browser is copied into Firefox browser's session. Also, it is logging in 2nd time at the same time which should not. This might be because, if you have provided your own UserPrincipal and UserPrincipalImpl classes, you have to override Object's equals() and hashCode() methods. Try it to make concurrency control working.

Also refer my question.

Upvotes: 1

Shaun the Sheep
Shaun the Sheep

Reputation: 22742

If you copied the cookie after you logged in (as you've said), then that is not a session-fixation attack (at least not of the kind we protect against). The point is that the cookie changes when you log in, so that someone else cannot access your account. If you want to stop someone fixing a session which is already logged into their account, then that is a different matter and isn't something that can easily be protected against in this way.

Also, you shouldn't need to set this attribute as it is enabled by default. And just use one <session-management> element.

Upvotes: 8

Related Questions