A very common way of handling user sessions in web applications is by placing a cookie in the user’s browser with a bit of information (such as a user session ID) that identifies that session on the application and lets the application give the appropriate rights to the requests coming from that specific browser. This also means that often, all a malicious actor needs to steal is that cookie in order to impersonate that user, making it a crucial piece of information to protect.
To do so, browsers implement a variety of flags and HTTP headers made to block a variety of attacks designed to steal the so precious session cookie. In a few recent Web application penetration tests we performed, we saw these security features only implemented partially, creating holes that a sophisticated malicious actor could use to bypass them. In this post, we’ll start with the simplest and possibly most important feature to protect your session ID cookies: the secure flag.
Turning on the Secure Flag Feature: A Non-Negotiable
If a cookie is set with the secure flag, the user’s browser will know to never send that cookie through unencrypted HTTP requests. Easy enough, right? The mistake that we see sometimes is developers neglecting to turn this feature on because they are planning to serve their application only through HTTPS. However, that makes the transmission of the cookie vulnerable to a man-in-the-middle attack.
If the attacker is positioned in a network in a way that he can monitor or intercept the requests, then he doesn’t have to do much to acquire the cookie: all he has to do is to trick the client into clicking a http:// link instead of a https:// one, and the browser will send the cookie in clear text in the HTTP request, which will be captured by the attacker.
Is that Enough to Protect Users Against Malicious Wi-Fi Hotspots?
If the attacker has some control over the network (e.g., by operating a malicious Wi-Fi hotspot that tricks users into connect to it, such as a Wi-Fi Pineapple, a realistic attack scenario in corporate networks), he can run a more complex man-in-the-middle attack by using a tool such as sslstrip, which transparently removes the encryption in the connection between the user and the attacker, and re-establishes it when connecting it to the application’s server, keeping the server none-the-wiser of the attack.
To protect against sslstrip, you would use the Strict-Transport-Security header on the application responses. Strict-Transport-Security notifies the user’s browser to never connect to the application without using encryption, stopping the browser from connecting in the case of an sslstrip attack. It’s not a perfect defense, as it is a “trust on first use” protocol: it’s only set correctly if the user connects to the real page once before being victim of an attack.
Beware of Misconfiguration
The moral of the story is, if a cookie contains information that will allow an attacker to steal a user’s session, make sure to turn on the secure flag as well as setting the Strict-Transport-Security header to prevent browsers from connecting insecurely to secure pages.