URL-Rewriting, referer and https

[sameergn]

Hi,

Our site is using URL rewriting for session tracking. As an added
security (although not fool-proof) we also check referer to be our own
site. All the links are currently http and we are planning to
introduce few https links.

Browser (correctly) does not send referer header when user clicks on
http URL from an https page and this is breaking our referer check. If
we remove referer check, then session hijacking becomes very easy as
URLs can be frequently passed in emails etc.

We are thinking of adding IP address check when URL is submitted back,
to make sure that it is coming from same IP, but it is not reliable as
IP can change frequently. (E.g when user moves from a wired to
wireless connection)

What would be a good security mechanism if we remove referer check and
still keep using URL-rewriting? I guess, cookie based sessions are
also vulnerable to session hijacking but it is more difficult to steal
cookie. (Since it is not easily visible in URL, only option is to
sniff the network, guess the cookie value, or steal it from user's
computer)

Thanks,
Sameer

 

[petersprc]

Wouldn't the server usually try a cookie first, then use URL rewriting
as a fallback? That seems to be what you want.

Session URLs expire eventually, making them harder to re-use by
passing them around. But yes, cookies would be just slightly more
secure in that the token would be less likely to show up in log files,
browser histories, and referrer strings. This might be negligible
though. If you need to prevent eavesdropping, all pages should be
secure.

If you wanted to keep the referrer check, you could make exceptions
for particular links to non-secure pages.

The main benefit of the referrer check IMO is preventing certain CSRF
vulnerabilities. However this protection isn't needed for all pages or
for all applications and may not apply to you.

 

[Tom Hawtin]

What would be a good security mechanism if we remove referer check and
still keep using URL-rewriting? I guess, cookie based sessions are
also vulnerable to session hijacking but it is more difficult to steal
cookie. (Since it is not easily visible in URL, only option is to
sniff the network, guess the cookie value, or steal it from user's
computer)

Something else to be aware of is that you don't necessarily have to
steal a session in order to do something dodgy with it. If I send you to
a malicious page with some JavaScript in it, that can POST to a third
party website that you are logged into using cookies or HTTP auth. (In a
Java Applet/WebStart application, I should only be able to GET using
AppletContext.showDocument or similar.)

JavaScript is evil.

Tom hawtin

 

[sameergn]

Something else to be aware of is that you don't necessarily have to
steal a session in order to do something dodgy with it. If I send you to
a malicious page with some JavaScript in it, that can POST to a third
party website that you are logged into using cookies or HTTP auth. (In a
Java Applet/WebStart application, I should only be able to GET using
AppletContext.showDocument or similar.)

JavaScript is evil.

Tom hawtin

Our server is configured currently to use only URL rewriting method,
so it does not use cookies at all. So our site works fine without
cookies.
Now, moving jsessionid to a cookie would mean that site would not work
(or some links will not work if server falls back to URL rewriting and
referer is absent during a transition from https->http) when user
disables cookies in their browser.

Do you think moving to cookie based approach is a good idea? I think
there are lots of sites out there (gmail, yahoo mail, Circuit City,
Wells Fargo, ING Direct) that do not work without cookies.

Thanks,
Sameer