CSRF attack detailed

Original: http://www.django-china.cn/topic/580/

What is a. csrf?

CSRF (Cross-site request forgery), Chinese name: cross-site requests forgery, also known as: one click Attack/session Riding, abbreviated as: CSRF/XSRF.

Two. What can csrf do?

You can understand that. CSRF attack: An attacker steals your identity and sends a malicious request on your behalf. The things that CSRF can do include: Send mail in your name, message, steal your account, even buy goods, virtual money transfer ... Issues include: personal privacy breaches and property security.

Three. CSRF Vulnerability status

Csrf This attack method in 2000 has been put forward by foreign security personnel, but at home, until 06 began to be concerned, 08, a number of large communities and interactive sites at home and abroad, respectively, CSRF loopholes, such as: NYTimes.com (New York Times), MetaFilter (a large blog site), YouTube and Baidu Hi ... Now, many sites on the Internet remain defenseless, so that the security industry calls CSRF "the Sleeping Giant".

Four. Principle of CSRF

The idea of CSRF attack is briefly expounded:

As you can see, to complete a csrf attack, the victim must complete two steps in turn:

1. Log on to trusted Web site A and generate cookies locally.

2. If you do not log out a, visit the dangerous website B.

See here, you may say: "If I do not meet one of the above two conditions, I will not be attacked by CSRF". Yes, it does, but you cannot guarantee that the following will not happen:

1. You cannot guarantee that once you have logged into a website, you will no longer open a tab page and visit another site.

2. You cannot guarantee that your local cookie will expire immediately after you close your browser, and that your last session has ended. (In fact, closing a browser does not end a session, but most people will mistakenly think that closing the browser is tantamount to quitting the login/end session ...) ）

3. The so-called attack site may be a trusted, often-visited website with other vulnerabilities.

Above about the idea of CSRF attack, I will use a few examples to detail the specific CSRF attack, here I take a bank transfer operation as an example (just an example, the real bank website is not so silly:>)

Example 1:

Bank website A, which completes bank transfer operations with a GET request, such as: http://www.mybank.com/Transfer.php?toBankId=11&money=1000

Dangerous website B, it contains a section of HTML code as follows:

First, you log in to the bank website A, then visit dangerous website B, Oh, then you will find that your bank account is 1000 dollars less ...

Why is that? The reason is that bank Web site a violates the HTTP specification and uses GET requests to update resources. Before you visit the dangerous website B, you have logged into bank A, and B in a GET request for third party resources (the third party here refers to the bank website, originally this is a legitimate request, but this is used by criminals), So your browser will take your bank website A's cookie to make a GET request to get the resource "http://www.mybank.com/Transfer.php?toBankId=11&money=1000", As a result, the Bank website server receives the request, thinks this is an update resource operation (transfers the operation), therefore immediately carries on the transfer operation ...

Example 2:

To eliminate the above problem, the bank decided to use the POST request to complete the transfer operation.

The Web Form for bank website A is as follows:

　　action=method="POST"> type=name=/></p> type=name=/> </p> type=value=/></p> </form>      

The background processing page transfer.php as follows:

 　　 <?php  Session_start ()  If  (isset ($_request[  ' tobankid ' ] && Isset ( Span class= "NV" >$_request[ ' money ' ])  { buy_stocks ($_request [ ' tobankid ' ], $_request
                               
                                [
                                 ' money ' ];  } ?>       
                                  

Dangerous site B, still just contains the HTML code:

As in Example 1, you first log on to bank site A, then visit dangerous sites B, and the results ..... As in Example 1, you do not have 1000 ~t_t again, the cause of this accident is: the bank used $_request to obtain the requested data, and $_request can obtain the data of the GET request, but also can get the data of the POST request, This causes the data in the spooler to not differentiate whether this is a GET request or a POST request. In PHP, you can use $_get and $_post to get the data for GET requests and post requests separately. In Java, there is an issue that does not differentiate between GET request data and post data for request data requests.

Example 3:

After the previous 2 painful lesson, the bank decided to get the request data method also changed, instead of $_post, only to obtain the POST request data, background processing page transfer.php code as follows:

<?php Session_start ()  If  (isset ($_post[  ' tobankid ' ] && Isset (　　　　Span class= "NV" >$_post[ ' money ' ])  { buy_stocks ($_post[ ' tobankid ' ], $_post　　　　[ ' money ' ];  } ?>          

However, dangerous website B has changed its code by changing the Times:

<scriptType="Text/javascript"> Function Steal () {iframe = document.frames["steal"];　　　　　　Iframe.document.Submit ("transfer"); }</script><bodyOnload="Steal ()"><iframeName="Steal"display="None"> <form method= "POST"  Name= "transfer" action= "http://www.myBank.com/Transfer.php" Span class= "NT" >> <input type= "hidden" na Me= "Tobankid" value= "one" >  <input type= "hidden" name= "money" value= "$" > </form> </iframe> </body></HTML>      

If the user still continues the above operation, unfortunately, the result will be missing 1000 blocks again ... Because here Dangerous website B secretly sent a POST request to the bank!

To summarize the above 3 examples, CSRF main attack mode is basically the above 3, of which the 1th, 2 is the most serious, because the trigger condition is very simple, a can be, and the 3rd is more troublesome, need to use JavaScript, So the opportunity to use is much less than the previous one, but in either case, the consequences can be severe, as long as the CSRF attack is triggered.

Understanding the above 3 attack modes, in fact, can be seen, CSRF attack is a web-based implicit authentication mechanism! Although the authentication mechanism of the Web can guarantee that a request is from a user's browser, there is no guarantee that the request was sent by the user!

Five. CSRF's defense

I summed up the information I saw, CSRF defense can be from the server and the client side, the defense effect is from the service side of the effect is better, and now the general CSRF Defense is also on the service side.

1. CSRF Defense on the service side

There are many ways to csrf the server, but the general idea is consistent, which is to add pseudo-random numbers to the client page.

(1). Cookie Hashing (all forms contain the same pseudo-random value):

This could be the simplest solution, because the attacker could not obtain a third-party cookie (theoretically), so the data in the form failed to construct:>

　　<?php//Construction of encrypted cookie information "DEFENSESCRF";  Setcookie("Cookie"$valueTime()+3600); >　　           　　　　 　　　　

Add a hash value to the form to certify that this is indeed a request sent by the user.

 　　 <?php 　　　　 $hash=Md5($_cookie[' Cookie ']); 　　 ?><formMethod="POST"action="Transfer.php"><inputType= "text" name= "Tobankid" >  <input type= "text" name= "money" > <input type= "hidden"  Name= "check" value= "<? $hash ; "> <input type=" Submit "name=" submit "value=" submit " > </FORM>           

Then the hash value is verified on the server side.

<?php 　　       If(Isset($_post[' Check '])){ 　　 $hash=md5 ($_cookie[ ' cookies ' );  if ($_post[ " Check '  ==  $hash  {　　  dojob (); } else { //...  } } else { //...  }?>          

This method personally feel can eliminate 99% of CSRF attack, there are 1% .... Since the user's cookie is easily stolen due to the XSS vulnerability of the website, this is another 1%. General attackers see the need to calculate the hash value, the basic will give up, some exceptions, so if you need 100% of the elimination, this is not the best way.

(2). Verification Code

The idea of this scenario is that each user submission requires a user to fill out a random string of images on the form .... This solution can completely solve the CSRF, but the personal feel that in terms of ease of use does not seem too good, and also heard that the usage of the verification code image involves a bug known as MHTML, may be affected in some versions of Microsoft IE.

(3). One-time Tokens (different forms contain a different pseudo-random value)

When implementing one-time tokens, it is important to note that "parallel sessions are compatible." If a user has two different forms open at the same time on a site, csrf protection should not affect his submission to any form. Consider what happens if the site generates a pseudo-random value to overwrite the previous pseudo-random value each time the form is loaded: The user can only successfully submit his last open form because all other forms contain illegal pseudo-random values. Care must be taken to ensure that CSRF protection does not affect tabbed browsing or browsing a site with multiple browser windows.

Here's my implementation:

1). First the token generation function (Gen_token ()):

<?php     gen_token//Here I am a greedy convenience, actually using rand () to derive the random number as a token, is also unsafe. MD5(uniqid(randtrue$token}       　　　　　　　　

2). Then the session token generation function (Gen_stoken ()):

 <?phpfunctionGen_stoken(){ 　　　　　　  $pToken =  "; If ($_session[stoken_name) Span class= "o" >==  $pToken ) { //no value, assign new value  $_session[stoken_name　　　　　　= gen_token (); }  Else{ //continue to use old values    } ?>     /span>                

3). The Web form generates a function that hides the input fields:

<?php function gen_input () { gen_stoken (); echo  "<input type =\ "hidden\" name=\ "  value=\ "" $_session[stoken_name]   "\" >  " } ?>          

4). Web Form structure:

 <?phpSession_Start();Include("Functions.Php);?> <form method= "POST"  Action= "transfer.php" > <input type=< Span class= "s" > "text" name= "Tobankid" > < Input type= "text" name= "money" > <? gen_input (); ?> <input type= "submit" name= "submit" value= "submit"  > </FORM>            

5). Server-side Check token:

This is very simple, it is no longer verbose here.

The above actually does not fully conform to the "Parallel session Compatibility" rule, you can modify on this basis.

In fact, there are many want to write, helpless Energy Limited, for the time being, add, if mistakes, please point out:>

PS: This afternoon when writing this document FF crashed once, wrote half of the article is not, depressed for a long time t_t ....

Six. References

[1]. Preventing CSRF

[2]. Security Corner:cross-site Request Forgeries

[3]. "In-depth analysis of cross-site request Forgery Vulnerability: Principle Analysis"

[4]. Cross-site request forgery of web security testing (CSRF)

[5]. "In-depth analysis of cross-site request Forgery Vulnerability: Example explanation"

[6].http://baike.baidu.com/view/1609487.htm

CSRF attack details (RPM)