PHP Security-session Hijacking

Session Hijacking

The most common attack method for a session is session hijacking. It is the generic term for all the means that an attacker can use to access other people's sessions. The first step in all of these techniques 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. The knowledge of session exposure and fixation in the previous sections can help you ensure that the session ID is only known to the server and legitimate users.

The principle of depth prevention (see chapter I) can be used in sessions where the unfortunate attacker knows that some obscure security measures provide some protection. As a security-concerned developer, your goal should be to make the aforementioned camouflage process more complex. Remember that no matter how small the obstacles are, your app will protect you.

The key to making the camouflage process more complex is to strengthen validation. The session ID is the first method of validation, and 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 the request and consider the inconsistent behavior to be suspicious. For example, although the header of the user-agent (the browser type that issued this request) is optional, the browser that emits the header usually does not change its value. If you have a 1234 of the session ID of the user after login has been using Mozillafirfox browser, suddenly converted into IE, this is more suspicious. For example, at this point you can use the requirements to enter a password to mitigate the risk, while in the wrong time, this is also a relatively small impact on legitimate users. You can use the following code to detect User-agent consistency:

<?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 Internet Explorer, when a user accesses a webpage and refreshes a webpage, the Accept header information is different, so the accept header cannot be used to judge consistency.

It is true that User-agent header information is consistent, but if the session ID is passed through a cookie (recommended way), it makes sense that if an attacker can obtain a session ID, he can also get other HTTP headers. Because cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, victims need to visit the attacker's website and expose all header information. All the attackers have to do is rebuild the head to prevent any check of the header information consistency.

The better approach is to produce a token in the URL that can be thought of as the second form of validation (albeit weaker). Using this method requires some programming work and there is no corresponding function in PHP. For example, assuming that the tag is saved in $token, you need to include it in all of your app'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 it easier to manage this delivery process, you might put the entire request string in a variable. You can attach this variable to all links so that you can easily change your code even if you don't use it at first.

The tag needs to contain unpredictable content, even if the attacker knows all the information about the HTTP headers sent by the victim's browser. One way is to generate a random string as a token:

<?php   $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 point, the capture tag will be more convenient than the predictive markup, and the attack needs to fetch both of them by passing the tokens in the URL and passing the session ID in the cookie. This way, unless an attacker is able to see all the HTTP requests that the victim sends to your app, the original information is available, because in this case all the content is exposed. This type of attack is very difficult to implement (so it is rare) to prevent it from needing to use SSL.

There is an expert warning not to rely on checking the consistency of user-agent. This is because the HTTP proxy server in the server cluster edits the user-agent, and multiple proxy servers in this cluster may be inconsistent when editing the value.

If you don't want to rely on checking for user-agent consistency. You can generate a random tag:

  <?php   $token = MD5 (Uniqid (rand (), TRUE));  $_session[' token '] = $token;   ? >

Although the security of this method is weaker, it is more reliable. The two methods above provide a powerful means of preventing session hijacking. What you need to do is to strike a balance between security and reliability.

The above is the PHP security-session hijacking content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

