Methods of php session hijacking and prevention
- 2020-11-18 06:08:35
- OfStack
session data exposure
Session data often contains 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 session data is stored in the server environment, rather than in a database or file system. Therefore, session data is naturally not exposed publicly.
Using SSL is a particularly effective means of minimizing the exposure of data as it travels between the server and the client. This is 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 replies is protected.
If your concern is the security of the session data store 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 encrypted storage and decryption read handler.
session hijacked
The most common attack on a session is session hijacking. It is the umbrella term for all the means an attacker can use to access someone else's session. The first step in all of these approaches is to obtain a legitimate session id to disguise as a legitimate user, so it is important to ensure that the session ID is not compromised. Previous knowledge of session exposure and fixation will help you ensure that session identification is only known to the server and legitimate users.
The principle of depth protection can be applied to a session, where the session identification is unfortunately known to the attacker, and some modest security measures can also provide some protection. As a developer concerned with security, your goal should be to complicate the aforementioned camouflage process. Remember that no matter how small the obstacle, it will be protected by your application.
The key to making the camouflage process more complex is to enhance verification. Session id is the primary method of validation, and you can supplement it with other data. All the data you can use is 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 "1" nature of the request and consider any behavior that is not "1" suspicious. For example, while the User-Agent header (the type of browser that issued this request) is optional, it usually does not change its value as long as it is the browser that issued it. If you have a user with a session id of 1234 logging in to Mozilla Firfox and suddenly switching to IE, this is suspicious. For example, you can mitigate the risk by asking for a password and have less impact on legitimate users in the event of a false alarm. You can detect the 1 tropism of User-Agent with the following code:
I have observed that in some versions of the IE browser, the Accept header sent out when a user normally visits a web page is different from the Accept header sent out when a web page is refreshed, so the Accept header cannot be used to determine the 1 sex.
Ensure that the ES45en-ES46en header message 1 is valid, but if the session id is passed through cookie (recommended), it is reasonable to assume that if an attacker can get the session ID, he can also get the other HTTP headers. Because the cookie exposure is related to a browser vulnerability or cross-site scripting vulnerability, the victim needs to access the attacker's website and expose all header information. All the attacker has to do is reconstruct the head to prevent any checking of the head information 1.
A better approach is to generate a pass 1 tag in URL, which you can think of as a second (albeit weaker) form of validation. Using this method requires a bit of programming work, and there is no corresponding functionality in PHP. For example, if the tag is stored in $token, you need to include it in all of your application's internal links:
To make this delivery easier to manage, you might want to put the entire request string in a variable. You can attach this variable to all links so that even if you didn't use this technique in the first place, you can easily make changes to your code in the future.
The tag needs to contain unpredictable content, even if the attacker knows all the information about the HTTP header sent by the victim's browser. 1 method is to generate a random string as a marker:
When you use random strings (like SHIFLETT), it is not realistic to predict them. At this point, capturing the tag will be more convenient than predicting the tag, by passing the tag in URL and the session id in cookie, both of which need to be captured at the time of the attack. Only if the attacker can see the original HTTP request sent by the victim to your application, in which case everything is exposed. This type of attack is very difficult to implement (and therefore rare), and it requires SSL to prevent it.
Experts warn against relying on checking User-ES69en for its 1 sex. This is because the HTTP proxy server in the server cluster edits ES71en-ES72en, and multiple proxy servers in this cluster may not edit this value. If you do not wish to rely on checking User-ES74en for its 1 - induced properties. You can generate 1 random tag:
The security of this method is weaker, but it is 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.
Session data often contains 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 session data is stored in the server environment, rather than in a database or file system. Therefore, session data is naturally not exposed publicly.
Using SSL is a particularly effective means of minimizing the exposure of data as it travels between the server and the client. This is 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 replies is protected.
If your concern is the security of the session data store 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 encrypted storage and decryption read handler.
session hijacked
The most common attack on a session is session hijacking. It is the umbrella term for all the means an attacker can use to access someone else's session. The first step in all of these approaches is to obtain a legitimate session id to disguise as a legitimate user, so it is important to ensure that the session ID is not compromised. Previous knowledge of session exposure and fixation will help you ensure that session identification is only known to the server and legitimate users.
The principle of depth protection can be applied to a session, where the session identification is unfortunately known to the attacker, and some modest security measures can also provide some protection. As a developer concerned with security, your goal should be to complicate the aforementioned camouflage process. Remember that no matter how small the obstacle, it will be protected by your application.
The key to making the camouflage process more complex is to enhance verification. Session id is the primary method of validation, and you can supplement it with other data. All the data you can use is 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 "1" nature of the request and consider any behavior that is not "1" suspicious. For example, while the User-Agent header (the type of browser that issued this request) is optional, it usually does not change its value as long as it is the browser that issued it. If you have a user with a session id of 1234 logging in to Mozilla Firfox and suddenly switching to IE, this is suspicious. For example, you can mitigate the risk by asking for a password and have less impact on legitimate users in the event of a false alarm. You can detect the 1 tropism of User-Agent with the following code:
<?php
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 the IE browser, the Accept header sent out when a user normally visits a web page is different from the Accept header sent out when a web page is refreshed, so the Accept header cannot be used to determine the 1 sex.
Ensure that the ES45en-ES46en header message 1 is valid, but if the session id is passed through cookie (recommended), it is reasonable to assume that if an attacker can get the session ID, he can also get the other HTTP headers. Because the cookie exposure is related to a browser vulnerability or cross-site scripting vulnerability, the victim needs to access the attacker's website and expose all header information. All the attacker has to do is reconstruct the head to prevent any checking of the head information 1.
A better approach is to generate a pass 1 tag in URL, which you can think of as a second (albeit weaker) form of validation. Using this method requires a bit of programming work, and there is no corresponding functionality in PHP. For example, if the tag is stored in $token, you need to include it in all of your application's internal links:
<?php
$url = array();
$html = array();
$url['token'] = rawurlencode($token);
$html['token'] = htmlentities($url['token'], ENT_QUOTES, 'UTF-8');
?>
<a href="index.php?token=<?php echo $html['token']; ?>">Click Here</a>
To make this delivery easier to manage, you might want to put the entire request string in a variable. You can attach this variable to all links so that even if you didn't use this technique in the first place, you can easily make changes to your code in the future.
The tag needs to contain unpredictable content, even if the attacker knows all the information about the HTTP header sent by the victim's browser. 1 method is to generate a random string as a marker:
<?php
$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';
$token = md5($string);
$_SESSION['token'] = $token;
?>
When you use random strings (like SHIFLETT), it is not realistic to predict them. At this point, capturing the tag will be more convenient than predicting the tag, by passing the tag in URL and the session id in cookie, both of which need to be captured at the time of the attack. Only if the attacker can see the original HTTP request sent by the victim to your application, in which case everything is exposed. This type of attack is very difficult to implement (and therefore rare), and it requires SSL to prevent it.
Experts warn against relying on checking User-ES69en for its 1 sex. This is because the HTTP proxy server in the server cluster edits ES71en-ES72en, and multiple proxy servers in this cluster may not edit this value. If you do not wish to rely on checking User-ES74en for its 1 - induced properties. You can generate 1 random tag:
<?php
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>
The security of this method is weaker, but it is 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.