What can CSRF do?

You can understand CSRF attack this way: the attacker stole your identity and sent malicious requests in your name. What CSRF can do includes: sending emails and messages in your name, stealing your account, even buying goods, virtual currency transfer... The problems caused include: personal privacy disclosure and property security.

CSRF attack principle

The following situations

1. You can't guarantee that after you log in to a website, you won't open a tab page and visit another website.

2. You cannot guarantee that your local Cookie will expire immediately after you close the browser, and your last session has ended. (in fact, closing the browser cannot end a session, but most people mistakenly think that closing the browser is equivalent to exiting the login / end session...)

Example 1:

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

Dangerous website B, which contains an HTML code as follows:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

First, you log in to bank website A, and then visit dangerous website B. Oh, at this time, you will find that your bank account is less than 1000 yuan

Why? The reason is that bank website A violates the HTTP specification and uses get request to update resources. Before visiting the dangerous website B, you have logged in to the bank website A, and the third party in B requests the third-party resources in the way of get (the third party here refers to the bank website, which was originally A legal request, but it was used by criminals). Therefore, your browser will bring the Cookie of your bank website A and send A get request to obtain the resources“ http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ”As A result, after receiving the request, the bank website server thought it was an update resource operation (transfer operation), so it immediately carried out the transfer operation

Example 2:

In order to eliminate the above problems, the bank decided to use POST request to complete the transfer operation.

The WEB form of bank website A is 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 is as follows:

　　<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
　　?>

Dangerous website B still only contains that HTML code:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

Like the operation in example 1, you first log in to the bank website A and then visit the dangerous website B. as A result... Like example 1, you lose 1000 ~ t again_ T. The reason for the accident is that the bank used it in the back office R E Q U E S T go Obtain take please seek of number according to ， and _ REQUEST to get the requested data, and R # REQUEST to obtain the requested data, and_ REQUEST can obtain both GET REQUEST data and POST REQUEST data, which makes the background handler unable to distinguish whether it is GET REQUEST data or POST REQUEST data. In PHP, you can use G E T and _ GET and G. ET and_ POST obtains the data of GET request and POST request respectively. In JAVA, like the request used to obtain request data, there is a problem that GET request data and POST data cannot be distinguished.

Example 3:

After the first two painful lessons, the bank decided to change the method of obtaining the requested data and use it instead$_ POST, only get the data requested by POST, and process the page transfer in the background The PHP code is as follows:

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
?>

However, dangerous website B keeps pace with the times. It changes the code:

<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 still continues the above operation, unfortunately, the result will be 1000 yuan missing again... Because dangerous website B secretly sent a POST request to the bank!

Summarize the above three examples

The main attack modes of CSRF are basically the above three, of which the first and second are the most serious. Because the trigger conditions are very simple, one can be used, while the third is more troublesome and requires JavaScript, so the use opportunities will be much less than the previous ones. However, in any case, as long as the CSRF attack is triggered, the consequences may be very serious.

By understanding the above three attack modes, we can see that CSRF attack is an implicit authentication mechanism derived from the WEB! Although the authentication mechanism of WEB can ensure that a request comes from a user's browser, it can not guarantee that the request is sent with the approval of the user!