[Esapi-user] Servlet spec and session fixation (was "Re: [OWASP-ESAPI] ESAPI Encryptor")
Kevin W. Wall
kevin.w.wall at gmail.com
Sat Jan 16 11:09:43 EST 2010
Holy sh*t Batman! Someone needs to address this as a JSR or something.
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.)
Ed Schaller wrote:
>> Personally, I would make sure that your developers are aware of and
>> mitigating against HTTP Session _Fixation_ attacks (see
>> http://www.owasp.org/index.php/Session_Fixation). With today's
>> app servers, this is much more likely to be a problem than is
>> HTTP Session _Prediction_ (see
>> http://www.owasp.org/index.php/Session_Prediction) which most
>> vendors have already addresses.
> On a completely unrelated note to crypto part, I did some analysis a
> few months ago on the servlet spec and it's requirements toward session
> state management and specifically toward session fixation which surprised
> me. I'll dig up the specifics if someone would like.
> The gist is that the servlet spec is vague at best and there is no
> requirement that the tracking token (eg: JSESSION) be changed at login,
> logout or even HttpSession#invalidate(). I know of no implementation
> that doesn't at least change the token when invalidate() is called
> but it appears completely possible that a naive, yet fully conformant,
> implementation wouldn't.
> To muddy the waters further, the spec does require that session state
> before login be maintained after login. If you set a session attribute
> before login it will still be there after login. This further leads to
> session fixation issues in the naive implementation as the easiest way
> to accomplish this is to not do a thing;) A better implementation would
> be to change the session tracking token without changing the actually
> session object which should prevent fixation and meet the spec.
> Such vagueness would seem a fertile ground for security issues. I
> would have tried to get some clarification in the 3.0 (thanks for the
> inspiration and your push for HTTPOnly Jeff) but it was too late.
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents." -- Nathaniel Borenstein, co-creator of MIME
More information about the Esapi-user