Shulou(Shulou.com)05/31 Report--

This article introduces what the CSRF code audit in Web security is like, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

Introduction of loopholes

The cross-site request attack, simply put, is that the attacker uses some technical means to deceive the user's browser to visit a website that he has authenticated and perform some operations (such as sending email, sending messages, and even property operations such as transferring money and buying goods). Because the browser has been authenticated, the website visited will be considered to be a real user action. This exploits a loophole in user authentication in web: simple authentication can only guarantee that the request comes from a user's browser, but not that the request itself is made voluntarily by the user.

The difference between P.S:XSS and CSRF:

XSS: XSS vulnerability-- construct a payload-- to send to the victim-- the victim clicks on to open-- the attacker acquires the victim's cookie-- attacker uses the victim cookie to complete the attack.

CSRF: CSRF vulnerability-construct payload-- to send to victim-victim click open-victim executes code-victim completes attack (unbeknownst)

Attack flowchart:

As you can see from the figure above, to complete a CSRF attack, the victim must complete two steps in turn:

1. Log in to trusted Web site An and generate Cookie locally.

two。 Without logging out of A, visit dangerous website B

If I do not meet one of the above two conditions, I will not be attacked by CSRF. Yes, that's true, but you can't guarantee that the following will not happen. After all, as I said before, csrf was unknowingly.

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

two。 You can't guarantee that your local Cookie expires immediately after you close the browser, and your last session has ended.

So CSRF is a difficult and dangerous loophole.

Principle (CSRF instance)

When we open or log in to a website, the browser and the server where the site is stored will have a cookies, and when the session does not end, you can use your permissions to operate on the site. However, the attacker takes advantage of this feature to let the victim trigger the form or statement we constructed, and then achieve what the attacker wants to achieve.

Let's explain first: the variable $XssReflex gets the value of the variable named input passed by get (the value is a string), and then outputs it directly through the echo () function. Note that the user input is not filtered in the middle

It is suggested that students should spend more time thinking about the difference between CSRF attack and XSS attack, which will be easier to understand compared with learning.

I set up an experimental environment locally and simulated a background login of a website.

And the password and user are both admin.

Generally speaking, backend administrators have the function of adding users, so click add users after a successful login (here, for demonstration, the administrator is not allowed to customize the account name and password, but to add default accounts and passwords)

Here is an added user. Let's add it to him.

The white space on the page has been added, so let's take a look at:

At this time, if we record the web address of the user who has just been added, can we add the user as long as we visit this address? To verify this idea, next we click logout to log in (clear cookie information)

Try to add the user's page address: www.csrf.cn/csrf/adduser.php before the browser input. Try to add the user directly, but without success, it jumps back to the previous login page.

Why? Because the adduser.php page needs to validate the session information in order to perform the appropriate action. So someone thought, "since we can't successfully access this page ourselves, can we deceive the administrator into visiting this page without knowing it?" . We use the admin user to log in again and create a new tab. At this point, assume that the administrator continues to visit website B.

There is a malicious link written by the attacker on page B, which induces us to click on it.

When I check the users again, I find that the backstage has unwittingly added users.

There's one more.

This is an example of using the CSRF vulnerability to add a background. As long as the user (the victim) clicks on the link, a CSRF attack is completed, although the user may not have the intention to perform the operation.

Now let's make a comparison:

Normal website: # Create your views here.def transfer (request): if request.method=='POST': username=request.POST.get ('username') to_username=request.POST.get (' to_username') monery=request.POST.get ('monery') print (username,to_username,monery) return render (request,'transfer.html') output: serious website

Account name:

The other party's account:

Amount of transfer:

Abnormal presence of Csrf: # views:def transfer (request): return render (request,'transfer.html')

Jump to the page where you added the user

There are four main strategies for vulnerability defense against CSRF attacks on the server side.

1. Verify the HTTP Referer field: according to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. In general, a request to access a secure and restricted page must come from the same site. For example, the transfer of a bank is completed by the user visiting the http://bank.test/test?page=10&userID=101&money=10000 page. The user must first log in to bank.test, and then trigger the transfer event by clicking the button on the page. When the user submits the request, the referer value of the transfer request will be the URL of the page where the transfer button is located (in this case, it is usually bank. The address at the beginning of the test domain name. If an attacker wants to carry out a CSRF attack on a bank website, he can only construct a request on his own website. When a user sends a request to the bank through the attacker's website, the Referer of the request is directed to the attacker's website. Therefore, to defend against CSRF attacks, the bank website only needs to verify its referer value for each transfer request, if it is bank. The domain name at the beginning of test indicates that the request comes from the bank's own website and is legal. If Referer is another website, it could be a CSRF attack, then the request is denied.

two。 Add token to the request address and verify: the CSRF attack is successful because the attacker can spoof the user's request, in which all user authentication information exists in the Cookie, so the attacker can directly use the user's own Cookie to pass security authentication without knowing the authentication information. Thus, the key to defense against CSRF attacks is to put information in the request that the attacker cannot forge, and the information does not exist in the Cookie. In view of this, the system developer can add a randomly generated token in the form of parameters to the HTTP request, and set up an interceptor on the server side to verify the token. If there is no token in the request or the token content is incorrect, it may be a CSRF attack and reject the request.

3. Customize the property and validate it in the HTTP header: the custom attribute method also uses token and validates. Unlike the previous method, instead of putting token in the HTTP request as a parameter, you put it in the custom property in the HTTP header. With the class XMLHttpRequest, you can add the HTTP header attribute csrftoken to all requests of this class at once, and put the token value in it. This solves the inconvenience of the former method of adding token to the request, and at the same time, the address requested through this class will not be recorded in the browser's address bar, and there is no need to worry that token will be leaked to other websites through Referer.

4. Add CAPTCHA and verify: add a random numeric or alphabetic CAPTCHA to the form to effectively contain CSRF attacks by forcing the user to interact with the application.

About Web security CSRF code audit is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.