Phpsession hijacking and prevention methods. Session Data exposure session data usually contains personal information and other sensitive data. For this reason, session data exposure is a common concern. In general, the exposed
Session Data exposure
Session Data usually contains personal information and other sensitive data. For this reason, session data exposure is a common concern. In general, the exposure scope is not very large, because session data is stored in the server environment, rather than in the database or file system. Therefore, session data will not be publicly exposed.
SSL is a particularly effective method that minimizes 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 protection layer over HTTP to protect all data in HTTP requests and responses.
If you are concerned about the security of the session data storage area, you can encrypt the session data so that you cannot read its content without the correct key. This is very easy to do in PHP. you only need to use session_set_save_handler () and write your own session encryption and decryption functions.
Session hijacking
Session hijacking is the most common attack method against Sessions. It is a general term for all means that attackers can use to access others' sessions. The first step of all these methods is to obtain a valid session id to pretend to be a valid user. Therefore, it is very important to ensure that the session id is not leaked. The previous knowledge about session exposure and fixation helps you ensure that session identifiers can only be known to servers and legitimate users.
The principle of deep defense can be used in Sessions. when the session identity is unfortunately known to attackers, some inconspicuous security measures will also provide some protection. As a security-oriented developer, your goal should be to make the above camouflage process more complex. Remember that no matter how small the obstacles are, they will be protected by your applications.
The key to making the camouflage process more complex is enhanced verification. Session identity is the primary method for verification, and you can use other data to supplement it. All the data you can use is only 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 request consistency and consider inconsistent behavior as suspicious behavior. For example, although the User-Agent (browser type that sends this request) header is optional, the value of the browser that sends this header does not change. If a user with a 1234 session id keeps using the Mozilla Firfox browser after logon and suddenly converts it to IE, this is suspicious. For example, you can use a password to reduce the risk. In addition, when a false positive is reported, the impact on legal users is also small. You can use the following code to check the User-Agent consistency:
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, the Accept header information sent when a user accesses a webpage normally is different from that sent when a webpage is refreshed. Therefore, the Accept header cannot be used to determine consistency.
Ensure that the information in the User-Agent header is consistent. However, if the session id is passed through cookies (recommended), it makes sense that if the attacker can obtain the session id, he can also obtain other HTTP headers. Because cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, victims need to access the attacker's website and expose all header information. All attackers have to do is re-create the header to prevent any checks on the header information consistency.
A better way is to pass a tag in the URL, which can be considered as the second form of verification (although weaker ). This method requires some programming work, and PHP does not have the corresponding functions. For example, if the tag is saved in $ token, you need to include it in the internal links of all your applications:
The code is as follows:
$ Url = array ();
$ Html = array ();
$ Url ['token'] = rawurlencode ($ token );
$ Html ['token'] = htmlentities ($ url ['token'], ENT_QUOTES, 'utf-8 ');
?>
"> Click Here
To facilitate management of this transfer process, you may put the entire request string in a variable. You can append this variable to all links, so that even if you didn't use this technique at the beginning, you can easily change your code in the future.
The flag must contain unpredictable content, even if the attacker knows all the information in the HTTP header sent by the victim's browser. One way is to generate a random string as a tag:
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. In this case, the capture tag is more convenient than the prediction tag. by passing the tag in the URL and passing the session id in the cookie, both of them must be captured during the attack. In this way, unless attackers can view the original information of all HTTP requests sent by the victim to your application, in which case all content is exposed. This attack method is very difficult to implement (so it is rare). to prevent it, you need to use SSL.
An expert warned not to rely on checking User-Agent consistency. This is because the HTTP proxy server in the server cluster will edit the User-Agent, and multiple proxy servers in the cluster may be inconsistent when editing this value. If you do not want to rely on checking the User-Agent consistency. You can generate a random tag:
The code is as follows:
$ Token = md5 (uniqid (rand (), TRUE ));
$ _ SESSION ['token'] = $ token;
?>
Although this method is less secure, it is more reliable. Both methods above provide a powerful means to prevent session hijacking. What you need to do is to balance security and reliability.
Http://www.bkjia.com/PHPjc/825127.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/825127.htmlTechArticlesession data exposure session data often contains personal information and other sensitive data. For this reason, session data exposure is a common concern. In general, the exposed...
