Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Filipe Almeida (filipernl.ist.utl.pt)
Date: Sun Feb 10 2002 - 14:16:38 CST
> -----Original Message-----
> From: webappsec-return-863-filipe=rnl.ist.utl.ptsecurityfocus.com
> 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
> is broken. It seems to me that the scheme is quite fragile and
> 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
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