> This is exactly what I meant with my last annotation:
> only POST requests are requests one cares about using this
> technique. These are all triggered by the user and should be
> sent to the server in a fairly predictable order. For GET
> requests this technique does not make any sense at all. If
> you want to have secure GETs, you MUST use SSL.

And how is the session id passed to the client? Via a hidden field in a
sensitive page? Or via a cookie with the path set to /sensitive/data. Or
the cookie is always there but is only updated on a sensitive page?
Either you are extending the window of opurtunity of the attack to the
time it takes a user to access two sensitive pages.
If you use a hidden field, all the attacker has to do is request the
sensitive page to get the new session id. In the case of cookies, just
use current cookie, but the attack window is even bigger.
Am I missing something? What is the propose of the "lock the second
request with the same session id?" approach if you can't guarantee the
second request if from the attacker. And in the case of only checking
session id's in post requests, the attacker has the time to process the
attack while the user is browsing pages.

What about the attack: perform the post and log out user? The client
will think the session has expired when it is prompted with a new log on
screen.

Either way, man in the middle attacks still work. You only make passive
sniffing attacks a bit more complex, but nothing out of the ordinary.

--
Filipe Almeida

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