[Esapi-user] Servlet spec and session fixation (was "Re: [OWASP-ESAPI] ESAPI Encryptor")

Jeff Williams jeff.williams at aspectsecurity.com
Sat Jan 16 11:56:22 EST 2010

I think we're just going to have to live with the fact that the
platforms we write applications on don't provide all the security
features we need. This is okay.  IP doesn't provide security and we have
to build it on top. TCP provides some help, but we still have lots to
add. SSL... and so on up the stack.

ESAPI helps this problem in three ways.  First, developers can use ESAPI
controls where their platform doesn't provide all the help necessary.

Second, we can reach out to platforms to try to get them to provide the
right controls in their framework. If they want to
wrap/hide/embed/copy/rip/mix/burn these controls great.  As long as
they're good.

Third, ESAPI is a place where the security and development community can
work together to figure out how to make security controls easier to use,
stronger, and higher assurance.


-----Original Message-----
From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Kevin W. Wall
Sent: Saturday, January 16, 2010 11:10 AM
To: Ed Schaller
Cc: ESAPI-Users
Subject: [Esapi-user] Servlet spec and session fixation (was "Re:

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
> state management and specifically toward session fixation which
> 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
> 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
> 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
Esapi-user mailing list
Esapi-user at lists.owasp.org

More information about the Esapi-user mailing list