Session Fixation

Session fixation ( in German as: " establishing a communication session " ) is an attack on a connection- type data communication between two computers.

• 3.1 of the user
• 3.2 of the service provider

Modus operandi

While the participants in a connectionless communication exchange messages without defined relative to each other at a connection- type communication first (Session session, engl. ) Is a logical connection is established. Thus, a computer can maintain more than one session at the same time, each session is identified with a unique, difficult as possible to guess session ID.

To perform the attack of this type, can the attacker from the attacked system exhibit a valid session ID and pushes them to the victims. The victim is authenticated then based on the session ID against the system to be attacked with his data, can also be the attacker to gain access to this system, as long as he previously defined session ID is valid. From this point, the attacker can prove to be a victim and spend spy or change data under whose rights context.

In contrast to session hijacking, the attacker therefore not attempted in the Session Fixation to hijack an existing session of the victim.

Techniques of imputing

This attack is most frequently encountered in the compromise of Web applications, so the following section refers exclusively to such a scenario. While it is relatively easy for the attacker usually to get a valid session ID, he has for the foist only a limited number of ways:

URL manipulations

Accepts the Web application session IDs as parameters of an HTTP GET or POST call, the attacker can foist the victim 's session ID using a manipulated URL. Such a manipulated URL might look as follows, where 30fz93 here would be the session ID:

Http://www.example.com/login.asp?session=30fz93 To obfuscate the contents and, in particular, the parameters of the URL, the attacker could also take advantage of a short URL service. The URL can be sent to the victim, for example, by e -mail or otherwise known or can be deposited as a link or as the destination of an HTML form on a website. In this method of imputing the attacker is always instructed that his victim opens the URL or submits a form. If the manipulated URL but used for example as a source URL for an image embedded in a Web page or e- mail image, even this would not be necessary. However, this can be prevented by a separate browser from the email client is used.

Cross -site scripting

If the Web application to compromising vulnerable to a cross-site scripting attack and the attacker can exploit this vulnerability via JavaScript code to introduce, he can here about foist a previously generated session ID.

Cross-site cooking

If the browser of the victim vulnerable to a cross-site Cooking attack, the attacker can foist the victim a cookie for the Web application to compromising, if this visited a completely different website through which the attacker has control.

Access to the victim's PC

If the attacker has physical access to the computer and the user account of his victim, he can store the session id directly in the browser of the victim. Alternatively, it can also be exhibit from the victim machine from a new session ID and to remember. Although it is then, strictly speaking, is no longer a foist, but spying the session ID, still belongs to the fixation attack of the session, this method also. A physical connection is not necessary if the attacker can remotely take control of the PC. This can be done either through a security hole in other applications or the operating system, a user account with administrative rights or via a Trojan horse.

Countermeasures

There are several safety measures both for the provider of the web service as well as for the user.

The user

The following measures are not foolproof against attacks by Session fixation, however, raise the technical hurdles for attackers.

• Internet users should be insured with web offerings, whether they are on the right page and if the page secure encryption methods such as SSL support (with SSL, taken by itself, can not prevent session fixation ).
• Internet users should always log a precaution after the visit of the Web service so that strangers can not recall the website in the browser's history to get the session ID of the user.
• At the Select Cookies are not often offered option " remember me ", as they then usually assigns a persistent cookie.
• When using Basic / Digest Authentication the browser and all its instances close ( as Basic / Digest Auth Logout not know ).

Of the service provider

• At the time of login a user no previous information should be taken on the identity of the user. This means a new session should always be assigned at login. Non-personal data for already existing session can certainly be incorporated into the new session.
• If not absolutely necessary, a non- logged in users should not be assigned to only one session.
• More useful even against the session hijacking measures also apply here: Sessions should have a timeout. Both a soft, engages in non- use, as well as a hard, which allows it to expire the session after a maximum time. The session ID should only have a limited validity and are replaced after a new session ID.
• Sessions should ( for example, a combination of user-agent identifier sent by the client and other header fields ) be bound to an IP address or a fingerprint of the client. If you try to use the session from a computer with a different IP address or a finger other than the original, this a new session should be assigned.