What is cookie hijacking

Session hijacking: session and security

With session hijacking, a valid session is hijacked by an attacker (hence the hijacking). After successful hijacking, the attacker can, in the worst case, take over the identity of the user and use the application on their behalf.

Sessions occur wherever web applications allow visitors to register and log in. The session turns the stateless protocol into a protocol with a status. The application can now check whether the visitor from single page A (e.g. product presentation) who changes to the single page (e.g. order) is the same visitor.

In our PHP installation, we get the information in the Session area, which settings are valid for the session and where the sessions are stored.

Interesting information is e.g. session.cache_expire and session.save_path


With the specification: session.cache_expire we see the specification 180. The session expires automatically after 180 minutes if the user does nothing more. This default time for the lifetime of a session can, however, also be set individually in PHP:

The command would now “end” the session after 5 minutes if the user is not active. However, the session (or the program) does not notice that the user is typing a text (or reading the website in peace) and then after 6 minutes wonders why he has to log in again. You can also see in banking applications that a timer runs down on the page until when the user is automatically logged out (i.e. the session expires).

In the picture the example from Sparda-Bank:

So if you need more than 10 minutes to type your transfer, you are out of luck :)

You didn’t register yourself, but were, and successfully, de-registered. Security is more important than comfort here, which is the right decision from the programmer!


In the standard installation of XAMPP, the sessions are stored in the \ xampp \ tmp directory. If we now look into the directory, we will find files with names like:

Let's use a session with a PHP program to see what the contents of the file look like.

A file is then created in the directory for the session with the file name:

The content of the file is:

When the program is run again, nothing seems to happen. This is not surprising either, since a valid session still exists and there is therefore no reason to create another session.

For sessions, a unique 32-digit combination of characters is assigned as the name after the prefix. The attacker cannot guess this.

If you share a server with other users (the website is on a shared host), the default setting is often such that everyone uses the same directory for the session files. However (depending on the settings of the host) this directory can be read out and thus also the sessions.

It is therefore not a good idea if the username and password were saved in the session, because it would be there in clear text:

The session file says:

That would be unfavorable, especially when you know that other people might “be able” to read the content of the session. It can also happen that your session data is not saved in files, but in cookies. These are saved on the user's computer. However, the question here is who else has access to the computer (think about the little brother or that you are sitting in the internet café).

Storage of the sessions by the user

Let's take a look at the transmitted headers of the website (there are extensions for browsers such as “Live HTTP headers”.

(click to enlarge)

A cookie is now also listed in the HTTP header. In the example above with the name PHPSESSID = 0506f678e63586de1496f331d6ecb4d6

If we look in Firefox under "Tools -> Settings -> Data protection -> Show cookies ..",

should our cookie reappear there:

The cookies are stored on the hard drive - in different places depending on the browser:

Internet Explorer 7: "Cookies" folder C: \ Documents and Settings \% username% \ Cookies
Firefox: Cookies.txt file C: \ Documents and Settings \% username% \ Application Data \ Mozilla \ Firefox \ Profiles \% profile folder%
Opera: cookies4.dat C: \ Documents and Settings \% username% \ Application Data \ Opera \ Opera \ profile.

Cookies and Security Issues

Cookies cannot be trusted either, although they look as if the content came purely from you. Cookies can be fudged by the attacker and hey presto you have a security problem again. The data from cookies must therefore be treated (disarmed) with the same care as other user entries.

For cookies:

  • Always set the domain (as precisely as possible)
  • Always set a path

The plug-in (or the extension for Firebug) in Firefox with the name Firecookie by Jan Odvarko can be used to control cookies.

(click to enlarge)

And then the cookie can be manipulated.

Steal session information

If the information is now transmitted to the attacker via XSS, it is only a small step to hijack the session. By transmitting, the attacker now knows where the “kidnapping victim” is to be met.

The information about the session is saved (for JavaScript)

The JavaScript looks like this:

If you find a bug, please let us know (no matter if typographical or content-related error).

With a mouse Mark the faulty point and take over with the following button:

After submitting it comes here feedback! Please do not send twice. Thanks.