What a .CSRF that?
CSRF (Cross-site request forgery), Chinese name: cross-site request forgery, also called: one click attack / session riding, abbreviated: CSRF / XSRF.
What two .CSRF can do?
You can understand CSRF attack: the attacker stole your identity to send malicious request on your behalf . CSRF can do things include: to send the name of your e-mail, messaging, steal your account, and even the purchase of goods, virtual currency transfer ...... problems caused include: disclosure of personal privacy and property safety.
Three .CSRF vulnerability status quo
Such CSRF attacks have been proposed in the 2000 foreign security personnel, but in the country, until in 2006 began to be concerned about, in 2008, a number of large domestic and international community and interactive website were broke CSRF vulnerabilities, such as: NYTimes .com (New York Times), Metafilter (a large BLOG site), YouTube, and Baidu HI ...... now, many sites on the Internet are still unprepared for this, so called CSRF security industry as "sleeping Giants".
Four principles .CSRF
The figure below illustrates a simple idea CSRF attacks:
As can be seen from the figure, to complete a CSRF attack, the victim must complete two steps in sequence :
1. Log in to trusted sites A, and generates Cookie locally.
2. In the case of A is not out of, access to dangerous websites B.
See here, you might say: "If I do not satisfy more than one of the two conditions, I would not be CSRF attack" . Yes, it does, but you can not guarantee that the situation will not occur:
1. You can not guarantee that you log on a web site, the page will not open a tab and visit another site.
2. You can not guarantee that after you close your browser, your local Cookie expire immediately, your last session has ended. (In fact, close your browser can not end a conversation, but most people will mistakenly believe that the browser is closed is equivalent to Log / end the session up ......)
3. The above figure called the attack site, a site may be frequently accessed trusted person other vulnerabilities exist.
The above is probably speaking for a moment thought CSRF attack, Now I will explain in detail the specific CSRF attack with a few examples, here I am with a bank transfer of the operation as an example (just an example, not a silly real bank website:> )
Example 1:
Banking site A, it GET request to complete the bank transfer operations, such as: http:? //Www.mybank.com/Transfer.php toBankId = 11 & money = 1000
Dangerous site B, it contains a piece of HTML code as follows:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
First of all, you log on the website of the bank A, then visit dangerous websites B, oh, then you will find your bank account less 1000 ......
Why is this so? The reason is the bank's website A violation of the HTTP specification, using a GET request to update the resource. Before accessing dangerous websites B, you are already logged banking site A, and B in the <img> GET way to request third-party resources (here refers to a third-party bank site, originally it was a legitimate request, but here are the unscrupulous elements), so your browser will bring your bank's website Cookie issue get a request to access to resources "http://www.mybank.com/Transfer.php?toBankId=11&money= 1000 ", the results of the bank web server receives the request, which is considered a resource update operation (transfer operation), so be immediately transfer operation ......
Example 2:
In order to prevent the above problems, the bank decided to switch to the POST request to complete the transfer operation.
WEB Form A banking site as follows:
<form action="Transfer.php" method="POST"> <p>ToBankId: <input type="text" name="toBankId" /></p> <p>Money: <input type="text" name="money" /></p> <p><input type="submit" value="Transfer" /></p> </form>
Background Processing page Transfer.php as follows:
<?php session_start(); if (isset($_REQUEST['toBankId'] && isset($_REQUEST['money'])) { buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']); } ?>
Dangerous site B, but still contains the phrase HTML code:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
And operating as in Example 1, you first log on the bank's website A, then visit dangerous websites B, and the results ..... 1 as an example, you once again not the 1000 ~ T_T, the cause of the accident is: bank background using $ _REQUEST to obtain data requested, and $ _REQUEST to obtain data either gET request, you can also get data POST requests, which resulted in the spooler can not distinguish between data in the end is a gET request or a POST request The data. In PHP, you may be used, respectively, and $ _POST $ _GET GET request to obtain data and POST requests. In JAVA, a request for acquiring data request problem can not be distinguished data GET and POST requests the same data.
Example 3:
After the previous two painful lesson, the bank decided to request data acquisition methods also changed, use $ _POST, get only the data POST request, page Transfer.php background processing code is as follows:
<?php session_start(); if (isset($_POST['toBankId'] && isset($_POST['money'])) { buy_stocks($_POST['toBankId'], $_POST['money']); } ?>
However, the danger website B times, it was renamed the code below:
<html> <head> <script type="text/javascript"> function steal() { iframe = document.frames["steal"]; iframe.document.Submit("transfer"); } </script> </head> <body onload="steal()"> <iframe name="steal" display="none"> <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php"> <input type="hidden" name="toBankId" value="11"> <input type="hidden" name="money" value="1000"> </form> </iframe> </body> </html>
If the user is still continuing the above operation, unfortunately, the result will be seen again ...... since 1000 where dangerous site B secretly sent a POST request to the bank!
Summarize three examples above, CSRF main mode of attack is basically more than three kinds, of which the first and second most serious kind, because the trigger condition is very simple, a <img> on it, while the third kind is too much trouble need to use JavaScript, so the opportunity to use will be much less than the previous, but in either case, as long as the trigger CSRF attack, the consequences are likely to be severe.
Understand the above three kinds of attack patterns, in fact, it can be seen, CSRF attacks from WEB implicit authentication mechanism! WEB authentication mechanism can guarantee that although a request from a user's browser, but can not guarantee that the request is sent by the user to approve!
Five .CSRF defense
I summarize the information to see what, CSRF defenses can start from both the server and client, the defense effect is working better results from the server, it is now generally CSRF defense also performed on the server.
1. The server perform CSRF defense
CSRF service side ways and like a lot, but the general idea is the same, that is, increase the client page pseudo-random number.
(1) .Cookie Hashing (include all forms with a pseudorandom value):
This is probably the easiest solution, because the attacker can not obtain third party Cookie (in theory), so the data in the form of construction will fail:>
<? PHP // constructor encrypted information Cookie $ value = "DefenseSCRF"; setcookie ( "the cookie", $ value , Time () +3600 ); ?>
Hash increase in value in the form to authenticate this is indeed a request sent by the user.
<?php $hash = md5($_COOKIE['cookie']); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <input type=”hidden” name=”hash” value=”<?=$hash;?>”> <input type=”submit” name=”submit” value=”Submit”> </form>
Then the server side authentication Hash value
<?php if(isset($_POST['check'])) { $hash = md5($_COOKIE['cookie']); if($_POST['check'] == $hash) { doJob(); } else { //... } } else { //... } ?>
This method has been personally feel can eliminate 99% of CSRF attacks, that have 1% of it .... because the user's Cookie is easy due to the XSS vulnerability of websites to steal, which is an additional 1%. General attackers see a need to count Hash values, the basic will to give up, except for certain, so if you need to eliminate 100%, this is not the best way.
(2) The verification code
The idea of this program is: every time a user submits requires users to fill in random string on a picture in the form, Eritrea .... this program can be completely solved CSRF, but personally feel that it seems not very good in terms of ease of use , and heard a verification code using the picture involves a Bug is known as MHTML is likely to be affected in some versions of Microsoft's IE.
(3) .One-Time Tokens (different form contains a different pseudo-random value)
In implementing One-Time Tokens, to note one thing: that is "compatible parallel sessions." If the user is on a site simultaneously open two different forms, CSRF protection measures should not affect his submission of any form. Consider the site generates a pseudo-random value to override what the previous pseudo-random value will occur if each time the form is loaded: You can only successfully submitted his final open form, because all other forms contain illegal pseudo-random value. Care must be taken to ensure the CSRF protection measures will not affect the tabbed browsing or use multiple browser windows to browse a site.
I realize the following:
1) First token generation function (gen_token ()):
<? PHP function gen_token () { // here I am for convenience's sake, in fact, single-use Rand () obtained random number as a token, but also unsafe. // This can refer to what I wrote Findbugs notes in "Random Object Once the Created and Used only" $ token = MD5 ( uniqid ( RAND (), to true )); return $ token ; }
. 2) is then Session token generation function (gen_stoken ()):
? < PHP function gen_stoken () { $ pToken = "" ; IF ( $ _SESSION [STOKEN_NAME] == $ pToken ) { // no value, assign a new value $ _SESSION [STOKEN_NAME] = gen_token (); } the else { // continue to use the old value } } ?>
3) .WEB form generation function hidden input fields:
<?php function gen_input() { gen_stoken(); echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\” value=\”" . $_SESSION[STOKEN_NAME] . “\”> “; } ?>
4) .WEB form the structure:
<?php session_start(); include(”functions.php”); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <? gen_input(); ?> <input type=”submit” name=”submit” value=”Submit”> </FORM>
5) check token server:
This is very simple, there is no longer a long-winded.
This fact does not fully comply with the above "compatible parallel session" rule, you can modify on this basis.
VI. References
[1].Preventing CSRF
[2].Security Corner: Cross-Site Request Forgeries
[3]. "Depth analysis of cross-site request forgery vulnerability: the principle of analysis"
[4]. "Cross-site request forgery Web security testing (CSRF)"
[5]. "Depth analysis of cross-site request forgery vulnerability: examples to explain."
[6].http://baike.baidu.com/view/1609487.htm
This article is reproduced to: https: //www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html