PHP Security-cross-site request forgery

Cross-site Request forgery

Cross-site request forgery (CSRF) is a class of attack methods that allow an attacker to send arbitrary HTTP requests through the victim. The victim referred to here is an unwitting accomplice, and all requests for forgery are initiated by him, not by the attacker. This makes it very difficult for you to determine which requests are part of a cross-site request forgery attack. In fact, if you don't deliberately prevent cross-site request forgery attacks, your application is likely to be vulnerable.

Consider the following simple application, which allows users to buy pens or pencils. The following form is included on the interface:

CODE:

<form action= "buy.php" method= "POST" >  <p>  item:  <select name= "Item" >    <option Name= "Pen" >pen</option>    <optionname= "pencil" >pencil</option>  </select>< br/>  Quantity: <input type= "text" name= "Quantity"/><br/> <input  type= "Submit" value= "Buy" />  </p>  </form>

An attacker would first use your app to gather some basic information. For example, an attacker who first accesses a form and discovers two table cells, item and quantity, also knows that the value of item will be a pencil or pen.

The following buy.php program processes the submission information for the form:

CODE:

<?php   session_start ();  $clean = Array ();   if (isset ($_request[' item '] &&isset ($_request[' quantity '))  {/    * Filter Input ($_request[' item '],$_ request[' quantity ') *     /if (Buy_item ($clean [' Item '], $clean [' Quantity '])    {      echo ' <p>thanks for Yourpurchase.</p> ';    }    else    {      echo ' <p>there is a problem with yourorder.</p> ';    }  }   ? >

The attacker would first use the form to observe its actions. For example, after buying a pencil, the attacker knew that a thank-you message would appear after the purchase was successful. With this in mind, an attacker would try to get the same goal by accessing the following URL to submit the data by using the Obtain method:

http://www.php.cn/

If successful, the attacker would now be able to raise the URL format of the purchase when a legitimate user accesses it. In this case, it is very easy to make a cross-site request forgery attack as long as the attacker causes the victim to access the URL.

Although there are several ways to initiate cross-site request forgery attacks, it is most common to use embedded resource slices. In order to understand the process of this attack, it is necessary to first understand how the browser requests these resources.

When you visit http://www.php.cn/(Figure 2-1), your browser will first request the resource identified by this URL. You can see the return content of the request by looking at the source file (HTML) of the page. Google's logo image was found after the browser resolved the return content. This image is represented by an IMG tag in HTML, and the SRC attribute of the tag represents the URL of the image. The browser then issued a request for the picture, the above two requests between the different points is only the URL of the difference.

Figure 2-1. Google's homepage

A CSRF attack can use an IMG tag to leverage Thisbehavior. Consider visiting a Web site with the following image identified inthe Source:

Based on the above principle, cross-site request forgery attacks can be implemented via an IMG tag. Consider what happens if you visit a webpage that includes the following source code:

Because buy.php scripts use $_request instead of $_post, each user who logs on to the store.example.org store buys 50 pencils by requesting the URL.

The existence of cross-site request forgery attacks is one of the reasons why $_request is not recommended.

The complete attack process is shown in Figure 2-2.

Figure 2-2. Cross-site request forgery attack via picture

When a picture is requested, some browsers change the accept value of the request header to give the picture type a higher priority. Protective measures need to be taken to prevent this from happening.

You need to use several steps to mitigate the risk of cross-site request forgery attacks. The general steps include using post instead of get to submit the form, using $_post instead of $_request when processing form submissions, and validating when important operations are needed (the more convenient and risky, the more you need to balance the convenience with the risk).

Any form that needs to be manipulated uses the Post method. In the 9.1.1 section of RFC2616 (http/1.1 Transfer Protocol), there is a description:

In particular, it should be noted that the customary get and head approach should not be used to raise an action, but only to obtain information. These methods should be considered ' safe '. The client browser should make the user aware that the operation being requested may not be secure in a special way, such as post,put or delete. ”

The most important thing is that you can force your own form to commit. Although user-submitted data appears to be the result of your form's submission, it is more suspicious if the user is not the form that was recently called. Take a look at the following code that applies the changes to the preceding precedent:

CODE:

<?php   session_start ();  $token = MD5 (Uniqid (rand (), TRUE));  $_session[' token '] = $token;  $_session[' token_time ' = Time ();   ? >   <form action= "buy.php" method= "POST" >  <input type= "hidden" name= "token" value= "<?php echo $ token;?> "/>  <p>  item:  <select name=" Item ">    <option name=" pen ">pen</ option>    <optionname= "pencil" >pencil</option>  </select><br/>  Quantity : <input type= "text" name= "Quantity"/><br/> <input  type= "Submit" value= "Buy"/>  </p >  </form>

With these simple modifications, a cross-site request forgery attack must include a valid verification code to fully mimic the form submission. Since the verification code is saved in the user's session, the attacker must use a different verification code for each victim. This effectively restricts any attack on one user, which requires the attacker to obtain a valid authentication code for another user. It is not valid to use your own verification code to forge another user's request.

The verification code can be checked simply by a conditional expression:

CODE:

<?php   if (isset ($_session[' token ')) &&      $_post[' token '] = = $_session[' token '])  {/    * Valid Token */  }   ?>

You can also add a valid time limit to the verification code, such as 5 minutes:

CODE:

<?php   $token _age = time ()-$_session[' token_time '];   if ($token _age <=)  {/    * Less than five minutes have passed. */  }   ?>

By including the verification code in your form, you have virtually eliminated the risk of cross-site request forgery attacks. You can use this process in any form where you want to perform an action.

Although I use the IMG tag to describe the attack method, the cross-site request forgery attack is a generic term that refers to the type of attack that all attackers make by forging other people's HTTP requests. The known attack methods also include attacks on Get and post, so don't assume that just using post is strictly the only way to do it.

The above is PHP security-cross-site request forgery content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

