[Owasp-testing] Copy Cookies

Dave van Stein dvstein at gmail.com
Thu Jul 22 05:19:06 EDT 2010


2010/7/22 Stephen de Vries <stephen at twisteddelight.org>

>
> On Jul 22, 2010, at 9:54 AM, Dave van Stein wrote:
> >
> > 2010/7/22 Stephen de Vries stephen at twisteddelight.org
> >
> > I wouldn't really call this a vulnerability, it's how 99% of the web
> applications on the internet work.
> >
> > And 95% of the application accept and use user input unvalidated ... Is
> that not a vulnerability either then ?
> >
> > Session hijacking IS a vulnerability. You can prevent it and it should be
> prevented.
>
> I didn't claim the contrary.  The original poster described taking a
> session cookie (not mentioning where he got it) and then using it in another
> browser to get access to another user's session.  This is like saying every
> app on the internet is vulnerable to authentication hijacking, because if I
> take your username and your password then I can login as you!
>
I have to disagree :) During authentication the application is basically
determining the trust of the user trying to log in. Usually a username and
password is al that is needed, but stronger mechanisms exist. After
authentication most users do not like to provide these credentials again for
each and every request so some sort of token is issued. This token is
therefor basically a trust token. In order for this trust to be legitimate
the application should have a mechanism to validate the authenticity of this
token. Just accepting any token that happens to be an active token is like
only asking for a username (and no password) and assuming everybody will
only use his/her username.


> What I was saying was that the controls around the session ID are focussed
> on preventing attackers from getting hold of the session ID in the first
> place.  Very few "high value" apps will need to defend against attacks where
> the attacker has already got hold of the session ID.
>
Oh, I agree on that one. For most applications it is sufficient to use an
unpredictable token, protect it and limiting the lifespan.
Nonetheless session hijacking remains a vulnerability but with an acceptable
residual risk.

The advice you posted is nice and complete, I agree 100% - and I like that
you qualified some of the controls with: "...for high value
applications...", which shows that for other apps some of those controls are
overkill.

Well, it is just a copy/paste from the Testing Guide, so I can't take the
credits for it :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-testing/attachments/20100722/fce59005/attachment.html 


More information about the Owasp-testing mailing list