Advanced session hijacking mitigation

[rjancewicz]

utilizing ssl_session_id (when mod_ssl is enabled) and ip/user-agent
when using raw http connections an additional check is done to ensure
that cooked are not copied between systems thus preventing session
hijacking

If a user with a valid CAS session attempts to copy another user's
cookie the existing CAS session will simply reestablish and the stolen
cookie will be invalidated.
While this could potentially create a denial of service; the risk is
limited to non-https connections.

In addition the isSSL function now utilizes the mod_ssl optional function ssl_is_https

[pames]

Can you remove the extra whitespace here (and in other functions)?

[pames]

Can you also add tests for this new functionality?

I should state that I'm not 100% sold on the benefit of this just yet, at least for 'default enabled' mode - seems like there are a lot of ways for it to go wrong, and arguably the app needs to fix the XSS that led them to stolen cookies in the first place. Plus this will probably break situations like someone taking a session cookie and pasting it into, e.g. curl via command line.

There's also a relatively recent addition to browsers called Channel ID, which attempts to solve a similar problem: http://www.browserauth.net/channel-bound-cookies

I know Chrome supports it, I don't know if IE/FF do, but it may be a better route to go than crafting a custom mechanism like this.

I'd be curious what others have to say.

[pames]

s/prefered/preferred/

[rjancewicz]

While I agree with you that httpOnly and channel-bound cookies are a better solution to they don't addresses those using antiquated browsers.

[pames]

I think if you're using a browser that doesn't support httpOnly in 2014 (>99% support since 2011 according to https://www.owasp.org/index.php/HttpOnly#Browsers_Supporting_HttpOnly), you have far bigger problems than session hijacking :-) Your whole system is going to get owned by a drive-by exploit.

As far as TLS-OBC goes, I think we'd need to find out browser support (Chrome supports it, and this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=680292 seems to indicate NSS might support it) as well as whether mod_ssl exposes this value.

I do think there could be some value to pin the session ID, but my other questions remain around:

1. Under what circumstances / timeframes do clients negotiate new session IDs (particularly differences between desktop and mobile). Since a failure would require a round trip to the CAS server, this would be particularly bad. I don't know the current status of resumption on iOS or Android, but this relatively recent StackOverflow post seems to indicate resumption wasn't supported without hackery on Android: http://stackoverflow.com/questions/14337667/httpsurlconnection-ssl-resumption-not-working

2. How does this behave with intermediate networking gear that does SSL termination, proxying, or load balancing?

In the case of TLS-OBC, #1 is solved because the client re-uses the same certificate, and #2 is likely solved because I doubt intermediate network gear would implement TLS-OBC.