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