[Owasp-testing] Copy Cookies
rahim.jina at owasp.org
Thu Jul 22 05:04:18 EDT 2010
I'm afraid that I'd be more inclined to agree with Stephen - controls in the
app should be built around protecting the session ID (e.g. general input
validation, httponly and secure flags on the cookie, re-issuing the token
and invalidating the old one when moving from HTTP to HTTPS, moving from
unauthenticated to authenticated and again when logging out, stopping
concurrent logins, etc, etc, blah, blah, and all the stuff you suggested!).
If someone could just get access to the token locally and copy and paste it
to another browser then you have bigger problems. When testing apps, I've
never been convinced that the old 'copy and paste the session token from one
machine to another' test provides any great benefit. I suppose it's always
helpful to try and think of a practical way that someone can just get access
to the token like this and if you can't, then that risk that an attacker is
going to be able to get the token like this is pretty low.
Tying the session ID to a particular location/IP is difficult as suggested.
Although I'm all for the cheesy 'security in depth' approach, it depends on
the purpose of the application and the type of data it is processing - the
solution should be fit for the purpose of the application. I.e. a variation
of all of the above is great if you're protecting a high-value application,
but who really cares about implementing all of this for a brocureware site
that sells lawn-mowers!
On 22 July 2010 08:54, Dave van Stein <dvstein at gmail.com> 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
> The problem is that many apps where you can abuse this probabely have more
> easy to exploit vulnerabilities to why bother exploiting it.
>> Owasp-testing mailing list
>> Owasp-testing at lists.owasp.org
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-testing