> -----Original Message-----
> From: webappsec-return-863-filipe=rnl.ist.utl.ptsecurityfocus.com
> [mailto:webappsec-return-863-filipe=rnl.ist.utl.ptsecurityfocus.com]
On
> Behalf Of Gregory Steuck
> Sent: domingo, 10 de Fevereiro de 2002 8:50
> To: Security Coordinator
> Cc: owaspowasp.org; webappsecsecurityfocus.com
> Subject: One time cookie (was: OWASP How to test cookie manipulation)
>
>
> Has anybody ever implemented this one time cookie scenario? Does it
> behave well in real life? I can imagine the following scenario which
> will break sessions and enrage application users: the client browser
> sends a request with current cookie and after the server accepted the
> cookie and invalidated it but before new cookie was received by the
> client something goes wrong (connection dies, client clicks stop being
> tired of waiting for the long query to finish, you name it). The
session
> is broken. It seems to me that the scheme is quite fragile and
difficult
> to get right. Any real life experiences?

So you just have to catch the Set-Cookie reply from the server, and
execute the next request faster than the client. The client will then be
denied access to the site while the attacker has full-control.

Also, don't forget that browsers usually request documents in parallel.
This will surely break if you need a session to retrieve content other
than html (images, applets, css, jsp,...) from the site. Frames can be a
problem too.

AFAIK, there is no added security by using this method, despite the fact
that the attacker has to execute the request a little faster, and it
will definitely break several of things.

--
Filipe Almeida

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]