Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Filipe Almeida (filipernl.ist.utl.pt)
Date: Thu Apr 25 2002 - 21:15:31 CDT
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
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.
> Ingo Struck wrote,
> So you have kinda two sessions: one real session (encrypted; the
> 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>