Disable and avoid using code that might allow an attacker to execute system commands remotely.
- Session fixation is an attack where the attacker provides a user with a valid session identifier. It's similar to session hijacking, but reversed. Instead of stealing a user's session ID, the attacker gives the user a session ID, one that the attacker controls. In both cases, the result will be that the user and the attacker are using the same session identifier. The purpose of the attack is the same. An attacker can assume the user's identity and share their access privileges. Of course, the session that the attacker provides will not be authenticated. It won't be attached to a logged in user yet. The attacker has to wait patiently. When the user eventually logs into the website again, the application stores a bit of data in the session file to remember that the user has logged in and should be allowed to view other pages. Now the attacker can take advantage of the shared session and visit access-restricted pages. Early session fixation attacks relied on websites which accepted session ID's sent in the URL or in form data. Fortunately, it's become uncommon to maintain session IDs in URL strings, in large part because of the threat of session fixation. For example, in 2002 PHP changed the default configuration to turn off this ability. However. session fixation remains a threat. An attacker can set the user's browser cookie to preferred session ID in other ways, such as using cross-site scripting, as in this example. It may also be possible to set the cookie data using a Person-in-the-Middle Attack. That is when an attacker inserts themselves in the line of communication between the browser and the web server. The attacker secretly relays, and possibly alters, the communication between the two computers. When done well, the attack will be invisible and the computers will believe that they're communicating directly. An attacker may take over a router or create an Evil Twin Wi-Fi router to position themselves in the middle. But Person-in-the-Middle attacks can also use malware and other techniques. How can we prevent session fixation? First, never accept session identifiers as GET or POST variables, only accept session identifiers from cookies. This removes the easiest way to set a session ID. This is likely the default setting, but it's worth being sure, especially in PHP, which used a different default in the past. Next, use cross-site scripting defenses. Validate input, sanitize output, send a content security policy, and use smart cookie settings like HTTPOnly, Secure, and Expire. Most importantly, use HTTPS. These steps keep cookies secure during storage and transmission. The best defense against session fixation attacks is to automatically regenerate the session identifier after the user logs in. When the user logs in, discard the old session ID and assign a new one. The session file and the data inside do not have to change, this is only a change to the identifier, the value stored in the cookie. Many web languages and frameworks offer a function which makes regeneration easy. Then, when the user's authenticated, their authorization will be stored in a session file linked to the new session ID. The attacker will have the old session ID and it will not have been granted access.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting