Hi Ed, <div><br></div><div>Two questions:</div><div><br></div><div>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)</div>
<div>2) is there a mapping or list with all these &#39;vulnerabilities by design&#39; (like the one covered below)?</div><div><br></div><div>Dinis Cruz</div><div><br><div class="gmail_quote">2010/1/16 Ed Schaller <span dir="ltr">&lt;<a href="mailto:schallee@darkmist.net">schallee@darkmist.net</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">&gt; No wonder things are so broken. I stopped reading the Servlet spec<br>
&gt; after the 1.0 release because it had grown so huge after that. The<br>
&gt; 3.0 spec was just released this past Dec, so it will be awhile until<br>
&gt; it is addressed. (BTW, I just checked and the 3.0 spec is 230 pages.)<br>
<br>
</div>I can&#39;t blame you on the size. Here&#39;s a slightly modified (removing<br>
work specific stuff and stuff for folks not as familiar with servlets)<br>
extract of my previous thoughts on this. It was based on the 2.4 servlet<br>
spec but still applies to the 2.5 and 3.0 specs (3.0 does provide a<br>
non-container specific logout method though):<br>
<br>
The specific section that was mentioned is SRV.12.10 &quot;Login and Logout.&quot;<br>
This describes the interactions between a session and a J2EE login. This<br>
is where it specifically states that the session object must remain the<br>
same before and after login if and only if (iff) the session has been<br>
created before login. It&#39;s worth mentioning here that JSPs by default<br>
will create a session.<br>
<br>
Additionally, there is not a one to one correspondence between the<br>
session tracking method (JSESSIONID cookie, jsessionid path parameter or<br>
ssl session id being the common and WAS supported ones) and the session<br>
object. The method used can be the same for different servlet contexts .<br>
The session object itself is required to be unique per servlet context<br>
though. This means that while the cookie for /app1 may be the same as<br>
the cookie for /app2 the attributes in the session for app1 are not<br>
accessible by app2 and vice versa. See SRV 7.3.<br>
<br>
This also implies that there is not a one to many correspondence between<br>
the tracking method and the session objects as there is nothing to say<br>
that the tracking method id or even the method itself cannot change<br>
during the session object&#39;s life.<br>
<br>
So a session fixation vulnerability could easily exist in any J2EE web<br>
application following the spec. It would seem that it would be easier to<br>
have the vulnerability than not. To follow the spec and not be vulnerable,<br>
the container could change either the tracking method or the session id at<br>
login time. This would not prevent an attacker from using the pre-login<br>
session id to attempt to add session attributes using non-authenticated<br>
pages but would prevent the attacker from using the session after login.<br>
<br>
The developer of an application could also invalidate the session<br>
object after a successful login but I see nothing that would require the<br>
session tracking id or method to change as a result of that. Potentially<br>
a conforming container could invalidate session without changing the<br>
session id in the cookie. It would be interesting to see what different<br>
servlet containers do.<br>
<br>
It is also interesting to note that the session object is not required to<br>
be linked to J2EE authentication. SRV 12.10 says that &quot;being logged in to<br>
a web application corresponds precisely to there being a valid non-null<br>
value in getUserPrincipal method [of the HttpServletRequest object.]&quot;<br>
Certainly they are linked in many containers (eg: tomcat) but they are<br>
not in WAS. This leads to the container specific logout issue that has<br>
been mentioned before. It also implies that a conforming container is<br>
not required to invalidate the session at logout time either. It would<br>
seem that in a compliant container session attributes from one login<br>
could survive both the logout of one user and the login of the next user<br>
depending on the container implementation.<br>
<br>
&gt;&gt;&gt;------&gt;<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAktR9KcACgkQ8kiOCKEpeEFYUwCfc60aUJZRjfZZXZSbTD9WvvB0<br>
+moAnRWBwNZlF93ZIMRH1IWtu3TUblU8<br>
=eXjR<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Esapi-user mailing list<br>
<a href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-user" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-user</a><br>
<br></blockquote></div><br></div>