[Esapi-user] Servlet spec and session fixation (was "Re: [OWASP-ESAPI] ESAPI Encryptor")
dinis.cruz at googlemail.com
Sat Jan 16 14:11:41 EST 2010
1) is there a version of the Servlet Spec that ONLY has the parts with
security implications? (surely not all 230 pages are about features and
requirements that have security implications)
2) is there a mapping or list with all these 'vulnerabilities by design'
(like the one covered below)?
2010/1/16 Ed Schaller <schallee at darkmist.net>
> > No wonder things are so broken. I stopped reading the Servlet spec
> > after the 1.0 release because it had grown so huge after that. The
> > 3.0 spec was just released this past Dec, so it will be awhile until
> > it is addressed. (BTW, I just checked and the 3.0 spec is 230 pages.)
> I can't blame you on the size. Here's a slightly modified (removing
> work specific stuff and stuff for folks not as familiar with servlets)
> extract of my previous thoughts on this. It was based on the 2.4 servlet
> spec but still applies to the 2.5 and 3.0 specs (3.0 does provide a
> non-container specific logout method though):
> The specific section that was mentioned is SRV.12.10 "Login and Logout."
> This describes the interactions between a session and a J2EE login. This
> is where it specifically states that the session object must remain the
> same before and after login if and only if (iff) the session has been
> created before login. It's worth mentioning here that JSPs by default
> will create a session.
> Additionally, there is not a one to one correspondence between the
> session tracking method (JSESSIONID cookie, jsessionid path parameter or
> ssl session id being the common and WAS supported ones) and the session
> object. The method used can be the same for different servlet contexts .
> The session object itself is required to be unique per servlet context
> though. This means that while the cookie for /app1 may be the same as
> the cookie for /app2 the attributes in the session for app1 are not
> accessible by app2 and vice versa. See SRV 7.3.
> This also implies that there is not a one to many correspondence between
> the tracking method and the session objects as there is nothing to say
> that the tracking method id or even the method itself cannot change
> during the session object's life.
> So a session fixation vulnerability could easily exist in any J2EE web
> application following the spec. It would seem that it would be easier to
> have the vulnerability than not. To follow the spec and not be vulnerable,
> the container could change either the tracking method or the session id at
> login time. This would not prevent an attacker from using the pre-login
> session id to attempt to add session attributes using non-authenticated
> pages but would prevent the attacker from using the session after login.
> The developer of an application could also invalidate the session
> object after a successful login but I see nothing that would require the
> session tracking id or method to change as a result of that. Potentially
> a conforming container could invalidate session without changing the
> session id in the cookie. It would be interesting to see what different
> servlet containers do.
> It is also interesting to note that the session object is not required to
> be linked to J2EE authentication. SRV 12.10 says that "being logged in to
> a web application corresponds precisely to there being a valid non-null
> value in getUserPrincipal method [of the HttpServletRequest object.]"
> Certainly they are linked in many containers (eg: tomcat) but they are
> not in WAS. This leads to the container specific logout issue that has
> been mentioned before. It also implies that a conforming container is
> not required to invalidate the session at logout time either. It would
> seem that in a compliant container session attributes from one login
> could survive both the logout of one user and the login of the next user
> depending on the container implementation.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user