This isn’t a specific attack, but rather a general class of attacks on a user’s session data. It can take a number of different forms:
- A man-in-the-middle attack, where an attacker snoops on session data as it travels over the wire (or wireless) network.
- Session forging, where an attacker uses a session ID (perhaps obtained through a man-in-the-middle attack) to pretend to be another user.
An example of these first two would be an attacker in a coffee shop using the shop’s wireless network to capture a session cookie. She could then use that cookie to impersonate the original user.
- A cookie-forging attack, where an attacker overrides the supposedly read-only data stored in a cookie.
There’s a long history of Web sites that have stored a cookie like IsLoggedIn=1 or even LoggedInAsUser=jacob. It’s dead simple to exploit these types of cookies. On a more subtle level, though, it’s never a good idea to trust anything stored in cookies; you never know who’s been poking at them.
- Session fixation, where an attacker tricks a user into setting or reseting the user’s session ID.
For example, PHP allows session identifiers to be passed in the URL (e.g., http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32). An attacker who tricks a user into clicking a link with a hard-coded session ID will cause the user to pick up that session. Session fixation has been used in phishing attacks to trick users into entering personal information into an account the attacker owns. He can later log into that account and retrieve the data.
- Session poisoning, where an attacker injects potentially dangerous data into a user’s session — usually through a Web form that the user submits to set session data.
A canonical example is a site that stores a simple user preference (like a page’s background color) in a cookie. An attacker could trick a user into clicking a link to submit a “color” that actually contains an XSS attack; if that color isn’t escaped, the user could again inject malicious code into the user’s environment.
The Solution – There are a number of general principles that can protect you from these attacks:
- Never allow session information to be contained in the URL. Django’s session framework simply doesn’t allow sessions to be contained in the URL.
- Don’t store data in cookies directly; instead, store a session ID that maps to session data stored on the back-end. If you use Django’s built-in session framework (i.e., session), this is handled automatically for you. The only cookie that the session framework uses is a single session ID; all the session data is stored in the database.
- Remember to escape session data if you display it in the template.
- Prevent attackers from spoofing session IDs whenever possible. Although it’s nearly impossible to detect someone who’s hijacked a session ID, Django does have built-in protection against a brute-force session attack. Session IDs are stored as hashes (instead of sequential numbers), which prevents a brute-force attack, and a user will always get a new session ID if she tries a nonexistent one, which prevents session fixation.
Notice that none of those principles and tools prevents man-in-the-middle attacks. These types of attacks are nearly impossible to detect. If your site allows logged-in users to see any sort of sensitive data, you should always serve that site over HTTPS. Additionally, if you have an SSL-enabled site, you should set the SESSION_COOKIE_SECURE setting to True; this will make Django only send session cookies over HTTPS.
