How to sniff cookies over HTTPS

We often test websites that only offer an HTTPS service on port 443 and no content over port 80. So when we highlight the fact that the session cookie doesn’t have the ‘secure’ flag set, the developers response is inevitably: “So what? The whole site is over HTTPS anyway, so what’s the point of setting the ‘secure’ flag?”

(If you’re not familiar with the ‘secure’ flag, it a cookie attribute set by the server that prevents the browser from sending that cookie over clear text connections. On typical sites with both clear text HTTP and encrypted HTTPS services, it’s a very useful feature to prevent sensitive session cookies from being transmitted in clear text)

But if there isn’t an HTTP service on port 80, then what’s the risk of not setting the ‘secure’ flag?

Well, let’s assume https://www.example.com is such a site; if an attacker is able to sniff the victim’s network (e.g. on a public WiFi network), then they could trick the user into visiting a url such as:

http://www.example.com:443

(Note the “HTTP” in the url) If the victim click’s that link (or loads an image from that link), then all cookies for www.example.com will be sent across the network in clear text HTTP to the SSL service on port 443. Of course, the SSL service will reject the request, but it will allow the connection which is enough for the cookie to traverse the network in the clear and be sniffed by attackers.

The moral of the story is to always set the ‘secure’ flag on sensitive cookies, such as session cookies, even if the entire site runs over encrypted HTTPS.

‍