[Esapi-user] Servlet spec and session fixation (was "Re: [OWASP-ESAPI] ESAPI Encryptor")
schallee at darkmist.net
Sat Jan 16 12:17:28 EST 2010
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100116/b2d8f39a/attachment.bin
More information about the Esapi-user