# Session Fixation

Occurs when one person can set another person’s session token. In most basic case, this happens when session tokens are accepted in GET or POST data.

**Example Attack scenario**

An attacker gives the victim a link and the victim goes to it (`vulnerable.com/sid=I_GAVE_YOU_THIS_SID`). It prompts for a login. If on login, the victim has the session id `I_GAVE_YOU_THIS_SID`, then it’s bad. The attacker who gave the sid can log in with that session id.

When trying to execute this attack as an attacker, `I_GAVE_YOU_THIS_SID` should ideally be a server-generated session id (an expired session id that was generated for the attacker by the server) so you can be sure that it's in the correct format.

In a secure web application, the `I_GAVE_YOU_THIS_SID` token wouldn't be reused. Upon logging in, it would be thrown away and another token would be given instead.

### XSS + Session Fixation

If an application doesn't generate a new session token upon logging in but rather reuses the old one for logging in, then that's a session fixation vulnerability. In that case, you can facilitate the session fixation attack by using XSS to set the session token.

In this example, the token is stored in a cookie and XSS is used to set that cookie:

```
http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>
```