Web security Related (ii): cross-site request forgery (CSRF/XSRF)

Introduction CSRF (Cross-site request forgery cross-site solicitation forgery, also known as "one click Attack" or Session Riding, usually abbreviated as CSRF or XSRF, is a malicious use of the site. Although it sounds like a cross-site script (XSS), it is very different from XSS and is almost at odds with the way it is attacked. XSS leverages trusted users within the site, while CSRF leverages trusted sites by disguising requests from trusted users. Compared to XSS attacks, csrf attacks are often less prevalent (and therefore have very few resources to protect against them) and are difficult to guard against, so they are considered more dangerous than XSS. Scene

One of the programmers, big God, is transferring money to his friend in an online bank.

　　

After the transfer, out of curiosity, God the Gods viewed the site's source files, as well as the request to capture the transfer.

God found that this site did not prevent csrf measures, and he also has a certain number of visits to the site, so he plans to embed a hidden iframe forgery request on his website (every 10s sent), to wait for fish bait, to pay their own transfer.

Website Source:

View Code

Forgery Request source code:

View Code

Fish fishes opens the website of God of great gods and browses the colorful content on it. At this point the result of the forgery request is this (to demonstrate the effect, remove the hidden):

　　

Because fish did not land, so the forgery request has been unable to execute, jumping back to the login page.

Fish fishes then remembers to log in to the online bank to inquire about the content, so he logged in to the Web bank.

At this point the result of the forgery request is this (to demonstrate the effect, remove the hidden):

Fish fishes will transfer 100 yuan to God in every 10 seconds.

　　

　　

Prevent CSRF

CSRF can be successful because the same browser will share cookies, that is, authentication and authentication through the authorization is not able to prevent csrf. So what should be done to prevent CSRF? In fact, the way to prevent CSRF is very simple, just make sure that the request is the site issued by their own can be. How do you make sure that the request is from your site? Asp. NET to judge requests in the form of tokens.

We need to generate a token on our page and send the token on request. You need to verify the cookies+token when processing the request.

　　

At this point the result of the forgery request is this (to demonstrate the effect, remove the hidden):

$.ajax

What happens if my request is not submitted through a form, but through Ajax? The result is that validation does not pass.

Why is it like this? We look back at the addition of @html.antiforgerytoken () after the page and the request changes.

1. More than one hidden field on the page, name __requestverificationtoken.

2. There is also one more field __requestverificationtoken in the request.

　　

Originally want to add this field, I also add one not to be able!

Ah! Why not? Forcing me to enlarge the recruit, research source to go!

　　

Oh! The original token should be taken from the form. But in Ajax, there is nothing in the form. What about the token? I put the token in the bowl, no, it's in the header.

JS Code:

View Code

On the server side, refer to Validateantiforgerytokenattribute and write a ajaxvalidateantiforgerytokenattribute:

View Code

The Validateantiforgerytoken is then replaced with Ajaxvalidateantiforgerytoken when called.

　　

It's done, it's a sense of accomplishment!

Global processing

If all the operation requests to add a validateantiforgerytoken or Ajaxvalidateantiforgerytoken, is not very troublesome? Can it be handled in a uniform place? The answer is a wide gauge.

Validateantiforgerytokenattribute inherit Iauthorizationfilter, then do a unified treatment in Authorizeattribute.

Extendedauthorizeattribute:

View Code

Then sign up at Filterconfig.

　　

FAQ:

1. What the hell is Bypasscsrfvalidationattribute? Don't you have a allowanonymousattribute?

If you do not need to do CSRF processing, such as attachment upload, you can add Bypasscsrfvalidationattribute on the corresponding controller or action.

Allowanonymousattribute not only bypasses the processing of CSRF, but also bypasses authentication and authentication. Bypasscsrfvalidationattribute bypasses CSRF but does not bypass authentication and authentication,

That is, Bypasscsrfvalidationattribute acts on those that are logged in or authorized.

2. Why only post requests are processed?

I developed a principle, query all with GET, operation with Post, and for the query request is not necessary to do CSRF processing. Everyone can arrange according to their own needs!

　　

3. Do I do a global deal, and then add Validateantiforgerytoken or Ajaxvalidateantiforgerytoken to the Controller or action, will it conflict?

Does not conflict, only the validation will do two times.

Web security Related (ii): cross-site request forgery (CSRF/XSRF)