Method for Determining CSRF attacks based on origin

When we want to use a CSRF vulnerability to attack, we usually load the vulnerability CSRF interface on a third-party site using resource requests, when users access this page, they will secretly send an http request to the vulnerability site, that is, the attack is successful. Instance exploitation code:

There are many ways to send http requests using resources. attributes with authentication information such as SRC and background are supported. img, script, and css can be used for tags.

When you normally use html tags to load the required resources, the corresponding types are consistent, such:
Script SRC: application/javascript
Img SRC: img/jpeg, img/png
The background-image of any tag corresponds to: img/jpeg, img/png

The opposite to normal loading is that the text/html type returned by the request interface when we conduct a CSRF attack, which is different from normal requests.
Let's take a look at the differences between normal and CSRF attacks in the browser:

// Img src CSRF comparison   // comparison of script src CSRF <script src =" http://www.bkjia.com/js/bdsug. js? V = 1.0.3.0 "> </script> <script src =" http://www.bkjia.com/index. php? Csrf = woyigui "> </script>

Let's take a look at their origin information:

We can see that the difference is that the http api requested by scripts and img is text/html, which is problematic and may be a CSRF attack.
Of course, some sites often request text/html types, such as the callback function api. For example:

// False alarm <script src = "http://www.bkjia.com/my/alert.html"> </script>

Based on the comparison and analysis above, we can do this in the browser:
1. If the resource request tag request on the current page is not a normal type of resource, prompt the user or block the request;
2. To prevent false positives, you can use other protection policies, such as blacklisting third-party domains.

If you have any defects, please contact me. Thank you.

From woyigui's blog www.woyigui.cn