Replacing each other while the participants in a connectionless communication messages without defined reference, is first a logical connection (with a connection-type communication session established, Eng. Session). So that a computer can have more than one session at the same time, each session is identified with a unique, difficult-to-guess session ID .
To carry out an attack of this type, the attacker has the system to be attacked issue a valid session ID and passes it on to the victim. If the victim then authenticates himself to the system to be attacked with his access data on the basis of this session ID, the attacker can also gain access to this system as long as the session ID he previously specified applies. From this point on, the attacker can pretend to be his victim and spy out or change data under his or her rights context.
In contrast to session hijacking , the attacker does not attempt to hijack an existing session from his victim with session fixation.
This attack is most common when web applications are compromised , which is why the following section refers only to such a scenario. While it is usually relatively easy for the attacker to get a valid session ID, he has only a limited number of options available for defeating it:
If the web application accepts session IDs as parameters of an HTTP -GET or -POST call, the attacker can hide the session ID from the victim with the help of a manipulated URL. Such a manipulated URL could look like this, where 30fz93 would be the session ID:
In order to disguise the content and especially the parameters of the URL, the attacker could also use a short URL service . The URL can, for example, be sent to the victim by e-mail or otherwise named, or it can be stored as a link or as the target of an HTML form on a website. With this method of slipping, the attacker always depends on the victim opening the URL or submitting a form. However, if the manipulated URL is used, for example, as a source URL for an image embedded in a website or email, this would not be necessary. However, this can be prevented by using an email client that is separate from the browser.
Cross site scripting
If the victim's browser is susceptible to a cross-site cooking attack, the attacker can impose a cookie on the victim for the web application to be compromised if the latter visits a completely different website over which the attacker has control.
Access to the victim's PC
If the attacker has physical access to the victim's computer and user account, he can store the session ID directly in his victim's browser. Alternatively, he can have a new session ID issued from his victim's computer and remember it. Although, strictly speaking, it is no longer a matter of inserting, but rather spying on the session ID, this method is also part of the session fixation attack. Physical access is not necessary if the attacker can gain control of the PC remotely. This can be done either through a security hole in other applications or the operating system, through a user account with administrative rights or through a Trojan horse .
There are several safeguards for both the web service provider and the user.
The following measures do not offer absolute security against attacks by session fixation, but they do lift the technical hurdles for attackers.
- Internet users should make sure that they are on the right page and that the website supports secure encryption methods such as SSL (although SSL, in itself, cannot prevent session fixation).
- To be on the safe side, Internet users should always log out after visiting the web service so that strangers cannot access the website again in the course of the browser in order to obtain the user's session ID.
- When using cookies, do not select the option "remember registration", which is often offered, as this usually assigns a persistent cookie.
- When using Basic / Digest Authentication, close the browser and all of its instances (since Basic / Digest Auth does not recognize a logout ).
- No previous information about the identity of the user should be inherited at the time a user logs in. This means that a new session should always be assigned when logging in. Non-personal data relating to the existing session can definitely be transferred to the new session.
- If not absolutely necessary, a user who is not logged in should not be assigned a session in the first place.
- Other measures that are already useful against session hijacking also apply here:
- Sessions should have a timeout. Both a soft one, which works when not in use, and a hard one, which lets the session expire after a maximum time. The session ID should also only have a limited validity and should be replaced by a new session ID after it has expired.
- Sessions should be bound to an IP address or a fingerprint of the client (for example a combination of user agent ID and other header fields sent by the client). If an attempt is made to use the session from a computer with a different IP address or fingerprint than the original, a new session should be assigned to it.
- The web application must offer a logout option. When logging out, both the session ID for the client (e.g. cookie) and the session object on the server must be deleted.