Session fixation is when an attacker tricks a user into using a provided session identifier that the hacker can then control.
- Session hijacking is an attack where a hacker steals a user's active session to gain unauthorized access to parts of a website. Sessions store user data in a file or database on the server. It's more secure to store data in sessions than in browser cookies because the data never leaves the server. It cannot be viewed in transit or in storage. However, a session reference identifier or session ID is stored in a browser cookie and like all cookies is vulnerable to theft. An attacker with a stolen session ID can access all of the data stored in the session. Even worse, they can impersonate a logged in user. Imagine that a user logs into a web application successfully. The web application stores a bit of data in the session file to remember that the user's logged in. This enables the user to click links and visit other pages without having to reauthenticate each time. I think of it a lot like a wristband which grants access to an event. With every request, the cookie with the session data will be sent. The web application will retrieve that ID and find the matching session file automatically. That's how sessions work. Then it will look in the session file to find that bit of data that indicates whether a user has been previously authenticated. If so, it allows the user to view the requested page. If not, it denies the request and most likely sends them to a log in page. An attacker who can send a request with the user's session ID in step one assumes any previous state set in the session. As far as the web server's concerned, the request is coming from the real user. The attacker is now the user and can do anything that the user can do. They can transfer money or make purchases. They can view and edit personal information. They can change the account email or password to log out the real user. They can send messages to friends or coworkers using their assumed identity, which could be part of a phishing attack. To get the session ID, an attacker can either read it from the browser's cookie file, for example, using a cross-site scripting attack, or they can view the data in transit. This is usually done by eavesdropping on an open WiFi network, like those in coffee shops, hotels, and airports. Using WiFi is like shouting data to an entire room. Any device that's listening can hear it. And eavesdropping software is easy to find. Here's a quick recap of how to prevent cross-site scripting and how to keep cookie data secure. You should validate input, sanitize output, use a content security policy, use cookie settings like HttpOnly, Secure, and Expire, and most importantly, use HTTPS. It's essential that login pages and any access-restricted pages use HTTPS. I recommend going further and using HTTPS on all website pages, all of them. It's easy to set up, provides a strong defense for the entire website, and has many other benefits. Don't forget to mark the session cookie as Secure. Without a Secure session cookie, any request to a non-SSL page on the same domain, even the first request before being redirected to HTTPS, could expose the cookie and the session ID. For most cookies, the Secure flag would be set in the code when it's defined, but for session cookies which are more global in scope, there's usually a global setting which may be in a separate configuration file. There are several other defenses against session hijacking. Expiring and removing old session files regularly is a best practice. Fewer sessions stored means fewer sessions which can be hijacked. A script can be run nightly which checks the last activity or login for all users and removes stale sessions. Or an expiration check can be performed whenever a request is received. Whenever possible, destroy the session when a user logs out. Don't just remove a user's authentication status from the session file. An attacker who possesses a session which is currently logged out could wait for the session to be logged in again before they use it. A strong defense against session hijacking is to regenerate session identifiers periodically and at key points. Regenerating a session ID invalidates any previously stolen session IDs. It's most important to regenerate the session ID after a successful login. Any existing session data is maintained. Only the identifier is updated. Regenerating a session ID forces attackers to find a recent session ID and is also a major defense against session fixation attacks. There are two commonly recommended defenses which I do not recommend. The user agent string describes the browser type being used. Testing to make sure it matches the user agent string used at login is not a strong defense. While the user is unlikely to change browsers between requests, the user agent string can be discovered and forged. Testing for an IP address which was used at login is not a strong defense, and it can cause problems. IP addresses may be shared among several users. A user and an attacker on the same WiFi network may have the same IP address. It's also unreliable for legitimate users on mobile networks who may change IP addresses while they're traveling. You can prevent session hijacking if you protect the session cookie, use HTTPS on all pages, and then expire, destroy, and regenerate sessions at key points.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting