[dev] Fwd: [Bug 1246] New - session hijacking using referer URL

[Eric Rostetter]

Quoting Salim Virani <me at salimvirani.com>:

> Rather than intercepting the attack by trying to obscure the referrer
> information, it might be worth considering strengthening the actual
> authentication method as well.

That is what https: and/or cookies do. ;)  The attack only works
when you don't provide either of those options.

> Implementing some kind of digest authentication would mitigate this and
> other attacks because the authentication mechanism would be more
> sophisticated than the simple sessionid token used now.

I'm not sure it would be any more sophisticated really.  Just less static.

>  It would also
> be stronger than a solution bolstering the existing authentication
> method with IP or referrer detection because those can be spoofed.

Can't use IP or referer because they can change (use behind a proxy,
user with dhcp, etc) or remain static across users (multi-user system,
etc).

> This method is already supported by later browsers at the HTTP layer
> but it could also be put together using a little javascript at the
> application layer. (An HTTP layer solution would be more secure as it
> wouldn't be prone to javascript sniffing and so on)
> 
> (See http://www.ietf.org/rfc/rfc2617.txt for a description of HTTP
> Digest Auth)

Not a good solution as it provides no logout (other than closing
the browser), only a login.

> I'm humbly throwing this out there as a suggestion.  I'm not familiar
> with IMP3 code or this scenario in detail.  Is this a reasonable
> suggestion?

I think a url director would be better in this case.  It is easier to
implement, solves the problem, and doesn't have any limitations.

The only problem with a url redirector would to be to make sure it
was used in all the correct places (e.g. that we don't miss some place
that generates a url, and leave it vulnerable via that path).

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!