Hi, Thanks a lot for your feedback. That's great that you're thinking of using Acegi/Spring Security in your course.
I believe the issue of session fixation attacks has been addressed (at least as far as logins through AbstractProcessingFilter go) by the introduction of the "invalidateSessionOnSuccessfulAuthentication" property (the issue was raised some time ago, and there is a related Jira issue, SEC-399). Admittedly, this was only included in 2.0-m1 code and the default value is "false" to avoid breaking existing code. We should consider making it default to "true" and perhaps backport it to the 1.0.7 release. It may also be a better idea to move the behaviour out of AbstractProcessingFilter in order to offer the same protection to all authentication methods. As you say, HttpSessionContextIntegrationFilter is an obvious place as it has full information on whether a session existed at the start of a request and whether a security context has been created during the request. Thanks again for your comments. We welcome any further suggestions you might have. All the best, Luke. Rohit Lists wrote: > Hello, > > First of all I wanted to thank you all for putting together this > wonderful framework. My name is Rohit Sethi and I work for a company > called Security Compass that specializes in application security. My > field of research is on Java EE web application security, and I'm > currently leading development of a class for the SANS institute that > focuses on how to create secure applications. > > I'm currently developing the "authentication" section of this course > and I am pushing for users to use Acegi over container-based auth, > JAAS, and proprietary protocols. There is one design decision, > however, that I'm having a tough time understanding the rationale > behind with respect to session management. Currently, the default > behavior (i.e. out of the tutorial) is for the session ID to be the > same before and after authentication. This was brought up earlier in > this mailing list in September 2006 under the thread "Changing the > session identifier after a successful login". The response at that > point was from Ben Alex saying "JSESSIONID is only ever sent over > HTTPS, thus avoiding the need to modify the session ID". > > Unfortunately, SSL alone does not protect against "session fixation > attacks". Mitja Kolšek has written an excellent paper outlining > dangers and attack vectors of session fixation[1]. Both Cross-site > Scripting (XSS) and Meta-tag injection are ways to fix another user's > cookie-based session ID regardless of whether or not it's transported > over SSL. Over 84% of websites are vulnerable to XSS [2][3] so this is > a very real threat. > > I ask you to consider having different session IDs before and after > authentication. Right now I am asking my students to use Acegi, and > then telling them to avoid session fixation attacks. While it is > possible to achieve the desired effect with some manual work, I think > everyone who uses Acegi should not have to worry about session > fixation - and I don't imagine it would be a very difficult change to > make (i.e. invalidate the existing JSESSIONID and retrieve a new one > transparently within the httpSessionContextIntegrationFilter). > > Regards, > > -Rohit > > [1] http://www.acros.si/papers/session_fixation.pdf > [2] http://www.webappsec.org/projects/statistics/ > [3] http://www.xssed.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- SpringSource http://www.springsource.com Registered in England and Wales: No. 5187766 Registered Office: A2 Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
