On 12/16/2004 03:13 AM, Thomas Schreiber wrote:
SESSION RIDING - A Widespread Vulnerability in Today's Web Applications
http://www.securenet.de/papers/Session_Riding.pdf
Nice work. I suspect this vulnerability is quite common and dangerous.
In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to
concentrate on secrets that are explicitly stored in the server-side
session record. But one can also use a secret that is computed on-the-fly:
secret = SHA1(site_secret, session_id)
or, in the absence of explicit sessions:
secret = SHA1(site_secret, user_id, user_password)
Above, site_secret is a fixed secret random string (160 bits of entropy)
that is specific to this site.
Since this does not require changes to the database schema, it may be
easier to apply at the critical points of existing systems.
Due to site_secret, an attacker cannot compute the secret even if he
knows session_id (say, due to an XSS attack). And importantly, the
presence of site_secret prevents the attacker from recovering session_id
via a dictionary attack if the user accidentally publishes a URL
containing the secret.
To minimize URL ugliness, you can safely truncate this secret to, say,
16 hexadecimal characters (64 bits). In fact, often even 10 hexadecimals
would suffice, since testing each guess for the secret requires
triggering an HTTP request *by the user's browser*, so the attack cannot
be effectively parallelized.
It's important that site_secret is specific to the site, not the server.
If more convenient, one can use just one server-wide secret, and redefine:
site_secret = (server_secret, site_identifier)
where site_identifier can be, for example, the canonical hostname.
Eran
