Although the issue is often overlooked, session hijacking continues to be a pervasive threat on the web. This solution is intended to mitigate the potential of session hijacking on Access Manager installations.

For the purpose of this article, session hijacking can be defined as the impersonation of a valid session in order to gain unauthorized access. On the web, session keys are usually stored in cookies, and they are the primary target for this type of exploit. Most sites do not take sufficient steps to protect session cookies, which leaves their users open to hijacking. The good news is that protecting an Access Manager installation from session hijacking is both possible and relatively simple to accomplish. Below are ways to protect your Access Manager sessions against the two most common types of cookie exploits: sidejacking and cross site scripting.

Sidejacking

Although this has been a known vector since cookies were first used, it became highly publicized after the introduction of Firesheep in 2010. This attack relies on the attacker being able to sniff traffic on unprotected networks, or by finding ways to divert traffic through a machine that they control (think unprotected WiFi networks and rogue APs). With this method, the attacker simply reads the session information in the cookie as it is sent from the browser. Depending on the security of the network, this attack can be both very easy to perform and highly effective.

By default, Access Manager attempts to mitigate this attack by tying the session to an IP address. This is not as effective as it would first appear, as the attacker and victim are often on the same private network and share the same public address. This method also causes problems for legitimate users if their DHCP assignment changes. Overall, I do not find this feature to be worth the trouble, and I recommend disabling it (NAGGlobalOptions NAGErrorOnIPMismatch=off in the advanced configuration).

By far the most effective way of protecting your sessions against sidejacking is to use SSL encryption. Many sites protect the login credentials with SSL but immediately drop the user back to an unencrypted session. This keeps the credentials protected over the wire, but it leaves the actual session vulnerable. By enabling SSL for all of your accelerators, you will protect the entire session. For protection against an SSL downgrade attack, or accidentally exposing the cookie when redirecting from HTTP to HTTPS, you will also want to enable secure cookies. This sets a flag on the session cookie that prevents the browser from sending it over a non-secure connection. This option is enabled under the Cookies Settings (Servers -> Configuration -> Reverse Proxies / Authentication).

You may wish to leave visitors on an unsecured connection and only upgrade to SSL when an authenticated session is established. Access Manager itself cannot do this, but it can easily be accomplished with an ADC. The following TCL script will perform this functionality on either an F5 or A10 appliance:

when HTTP_REQUEST {
if { [HTTP::cookie exists "authenticated"] && [TCP::local_port] != 443} {
HTTP::respond 302 Location https://[HTTP::host][HTTP::uri]
}
}

when HTTP_RESPONSE {
if { [HTTP::cookie exists "IPCZQX03a36c6c0a"] } {
set cookiedomain [HTTP::cookie domain "IPCZQX03a36c6c0a"]
HTTP::cookie secure "IPCZQX03a36c6c0a" enable
HTTP::cookie insert name "authenticated" value "true" domain $cookiedomain path "/"
}
}

Simply add this script and enable for port 80 and 443 on the VIP(s) fronting Access Manager. This script will allow a connection to be made over HTTP if the user is not authenticated, but it will enforce HTTPS if the user has logged in.

Cross Site Scripting

A lot of bad things can be done with a well-executed XSS attack on your site, including widespread session hijacking. While XSS prevention is outside the scope of this article, you can make it more difficult for an XSS exploit to read session cookies. Modern browsers will prevent client side scripts from reading cookie data if the cookie is properly flagged. This flag is known as HttpOnly, and it can be enabled in Access Manager under the Cookies Settings (Servers -> Configuration -> Reverse Proxies / Authentication). Unless you know that there is a legitimate reason for client side scripts to access session cookie data, this option should be enabled.

Conclusion

While it is difficult to anticipate every type of attack that can be performed on your site or against your user base, this article should give you a good starting point on preventing the most common types of session attacks. Be safe out there!