There are several problems associated with this approach.
- Browser connections are usually multithreaded, so multiple requests
may be made with the same session id. You cannot guarantee the browser
will serialize the requests (gifs, etc...)
- If you open a new window, or a window pops up, you will desynch your
session counter allowing only one of the windows to work.
- Pages that spawn over multiple frames won't work.

Although allowing a session id to be used only once may mitigate the
effects of a replay attack, it won't protect you against man in the
middle attacks.
An active attack would be something like:
Proxy all the requests made by the client to the server. When the proxy
receives a new session id from the server, store it and use it for the
next request. Pass the client a fixed session id. You can inject all the
requests you like because the server is not authenticated.

Presently, I believe the best approach is to use two session ids (SSL
and no SSL), and transmit all sensitive data thru SSL connections.

Regards,
Filipe Almeida

> Ingo Struck wrote,
> So you have kinda two sessions: one real session (encrypted; the
server
> must not accept session ids that were not generated by himself, so he
> has to keep book over the generated session ids) and one
> per-request-session that changes with every response.

--
Filipe Almeida
<Filipernl.ist.utl.pt>

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