PHP session hijacking and prevention methods_PHP tutorial-PHP Tutorial-php.cn

PHP session hijacking and prevention methods_PHP tutorial

WBOY

Release： 2016-07-13 10:25:22

Original

918 people have browsed it

session data exposure
Session data often contains some personal information and other sensitive data. For this reason, exposure of session data is a common concern. Generally speaking, the scope of exposure is not very large because the session data is saved in the server environment, not in the database or file system. Therefore, session data is naturally not exposed publicly.
Using SSL is a particularly effective means of minimizing the possibility of data being exposed when transmitted between the server and the client. This is very important for applications that transmit sensitive data. SSL provides a layer of protection on top of HTTP so that all data in HTTP requests and responses is protected.
If you are concerned about the security of the session data save area itself, you can encrypt the session data so that its contents cannot be read without the correct key. This is very easy to do in PHP, you just use session_set_save_handler() and write your own session encryption storage and decryption reading processing functions.
session hijacking
The most common attack method against sessions is session hijacking. It is a general term for all the means an attacker can use to gain access to other people's sessions. The first step in all these methods is to obtain a legitimate session ID to pretend to be a legitimate user, so it is very important to ensure that the session ID is not leaked. The previous knowledge about session exposure and pinning can help you ensure that the session identifier is known only to the server and legitimate users.
The principle of defense in depth can be applied to sessions. When the session ID is unfortunately known to an attacker, some inconspicuous security measures will also provide some protection. As a developer concerned with security, your goal should be to make the aforementioned disguise process more sophisticated. Remember that no matter how small the obstacle is, your application will provide protection.
The key to making the disguise process more complex is to strengthen the verification. The session ID is the primary method of authentication, but you can supplement it with other data. All the data you can use is just the data in each HTTP request:
GET / HTTP/1.1
Host: example.org
User-Agent: Firefox/1.0
Accept: text/html , image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
You should be aware of the consistency of requests and consider inconsistent behavior as suspicious. For example, although the User-Agent (the type of browser that issued this request) header is optional, the browser that issues the header usually does not change its value. If a user with a session ID of 1234 has been using the Mozilla Firefox browser after logging in, and suddenly switches to IE, this would be suspicious. For example, you can mitigate the risk by requiring a password at this time. At the same time, in the event of a false alarm, this will have less impact on legitimate users. You can use the following code to check the consistency of User-Agent:

Copy the code The code is as follows:

session_start();
if (isset($_SESSION['HTTP_USER_AGENT']))
{
if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT' ]))
{
/* Prompt for password */
exit;
}
}
else
{
$_SESSION['HTTP_USER_AGENT'] = md5 ($_SERVER['HTTP_USER_AGENT']);
}

?>

I have observed that in some versions of IE browsers, users normally access a The Accept header information sent when a web page and a web page are refreshed are different, so the Accept header cannot be used to determine consistency.
It is indeed effective to ensure that the User-Agent header information is consistent, but if the session ID is passed through a cookie (the recommended method), it makes sense that if the attacker can obtain the session ID, he can also obtain other HTTP headers. Since cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, the victim needs to visit the attacker's website and expose all header information. All the attacker has to do is reconstruct the header to prevent any consistency check of the header information.
A better approach is to pass a tag in the URL, which can be thought of as a second (albeit weaker) form of validation. Using this method requires some programming work, and there is no corresponding function in PHP. For example, assuming the token is stored in $token, you need to include it in all internal links in your app: >

$url = array();$html = array();$url['token'] = rawurlencode($token);$html['token'] = htmlentities($url['token'], ENT_QUOTES, 'UTF-8');

Click Here

To make it easier to manage this delivery process, you might put the entire request string in a variable. You can append this variable to all links so that even if you don't use this technique initially, you can still easily make changes to your code later.
This tag needs to contain unpredictable content, even if the attacker knows all the HTTP header information sent by the victim's browser. One way is to generate a random string as a tag:

Copy the code The code is as follows:

$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';
$token = md5($string);
$_SESSION['token'] = $token;
?>

When you use a random string (such as SHIFLETT), it is unrealistic to predict it. At this time, capturing the tag will be more convenient than predicting the tag. By passing the tag in the URL and passing the session ID in the cookie, the attack needs to capture them both at the same time. This is unless the attacker can view the raw information of all HTTP requests sent by the victim to your application, because in this case everything is exposed. This attack is very difficult to implement (and therefore rare), and preventing it requires the use of SSL.
Some experts warn against relying on checking User-Agent consistency. This is because the HTTP proxy server in the server cluster edits User-Agent, and multiple proxy servers in this cluster may be inconsistent when editing this value. If you don't want to rely on checking User-Agent consistency. You can generate a random token:

Copy the code The code is as follows:

$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>

Although the security of this method is weak Some, but it's more reliable. Both of the above methods provide powerful means to prevent session hijacking. What you need to do is strike a balance between security and reliability.