CSRF Attack and Defense and CSRF AttacK Defense

CSRF Attack and Defense and CSRF AttacK Defense

Overview

 

CSRF is short for Cross Site Request Forgery, and Chinese is Cross Site Request Forgery. Next we will share with you the principles, implementation methods, and defense methods of this attack;

 

Principles of CSRF attacks

 

By deploying attack code and related data on a malicious website, and then guiding authorized users of the target website to access the malicious website, the browser has obtained the user authorization ticket of the target website, therefore, malicious websites can execute pre-deployed code to submit data to the target website so that the target website can perform some write operations, for example, you can delete the data of the target website and submit junk data to the target website. However, this process is performed silently in the background and users have no idea.

 

Here is an example:

 

Suppose www.t.com is the target website and there is a page www.t.com/blog/delete.aspx? Id = 123 indicates the operation to delete a blog post whose ID is 123;

Then attackers can deploy the following code on the malicious website www.a.com/csrfpage.aspxpage:

<Form id = "csrffrm" action = "http://www.t.com/blog/delete.aspx" target = "hideiframe"> <input name = "id" type = "hidden" value = "123"/> </form>

<Iframe name = "hideiframe" style = 'display: none'> </iframe>

<Script>

Document. getElementById ("csrffrm"). submit ();

</Script>

 

Attackers can then use various methods to attract users who have successfully logged on to www.t.com and click

 

CSRF attack Conditions

 

According to the above principle, we can see that the following conditions must be met for the implementation of CSRF Attacks:

 

1. You need to know the directory of the target system and related parameter names. In fact, it is not difficult to meet this condition, the attacker detects the system directory using the related "system directory rainbow table", or the attacker is also one of the users of the target system, so it is easier to understand the target system;

2. A website that executes malicious code may be a website deployed by an attacker in advance, or the XSS vulnerability of a malicious website may be exploited by attackers;

3. Users of the target system are required to log on and obtain valid operation permissions. At the same time, users are tempted to access malicious websites;

 

The implementation of CSRF attacks must meet these three conditions. Because these conditions are not so easily met, they are easily ignored by developers.

 

Protection Policy for CSRF attacks

 

1. Use the verification code

I remember that on the previous 12306 website, I had to enter a disgusting verification code every time I checked the ticket. The purpose of this verification code was to prevent the machine from refreshing the ticket. Of course, it could also effectively prevent CSRF attacks, however, if each operation requires the user to enter the verification code, the user may crash and the user experience is very poor;

 

2. Check Referer (source)

Besides the verification code, you can also check whether the Referer is from the same source. If the Referer is from the same source, this operation is credible. This method is usually used to prevent image leeching, however, sometimes the Referer is not so reliable, and the server is not. For example, if the user enables the browser's privacy policy, the browser may block the sending of Referer, the server may not be able to obtain this value, so this method does not comply with scientific and rigorous principles;

 

3. Use token (random token)

The server generates a random token and saves it. It can be saved in the session set of the server, the cookie of the client, or the page view status, due to the same-origin policy of the browser, the malicious Website Cannot read the cookie and page view status of the target website, submit the random token along with the form, and verify the validity of the random token on the server;

 

How can we avoid CSRF attacks?

CSRF is a type of vulnerability that is hard to prevent. According to my understanding, there is no good method to monitor CSRF. Some feasible preventive methods:

Do not use online banking. Since I don't need online banking, hackers will naturally find it hard for me to be helpless. (Just a joke :))
Change the password periodically. Regular password modification is always the most recommended method in security science.
After accessing sensitive websites (such as credit cards and online banking), you can actively clear historical records, cookie records, form records, and password records, and restart your browser to access other websites.
Keep the browser updated, especially the security patch. At the same time, pay attention to the updates of operating systems, anti-virus, firewall and other software.
Do not use websites with unknown origins. We recommend that you use the site authentication function of ms ie7 or google toolbar to identify illegal websites.
Use some browsers with the "Privacy Browser" function, such as Safari. The "private browsing" function allows users to surf the Internet without leaving any trace, and the browser does not store cookies and any other information. Therefore, CSRF cannot obtain useful information.
Ie8 calls it "InPrivate browsing ". Chrome is called "Incognito mode ".
If the browser prompts a warning message "the link and certificate domain name do not match", do not continue browsing, immediately close the browser or return to the previous page (if you are a web developer or hacker, when I do not say ).
Manage the cookies of the browser. For example, in IE6.0, open "tool-> Intern

Csrf

Cross-site request forgery: Cross-site request forgery, also known as "one click attack" or session riding, usually abbreviated as CSRF or XSRF, is a malicious use of the website. Although it sounds like XSS, it is very different from XSS, and the attack method is almost different. XSS uses trusted users in the site, while CSRF uses trusted websites by disguising requests from trusted users. Compared with XSS attacks, CSRF attacks are often less popular (so the resources to prevent them are quite scarce) and difficult to prevent. Therefore, XSS attacks are considered to be more dangerous than XSS attacks.
Examples and features
«Snapshot «‹›»
CSRF attacks work by Adding links or scripts to pages authorized to users. For example, Bob, a website user, may be browsing a chat forum, while Alice, another user, also posted an image message with Bob bank links. Assume that Alice has compiled a form submission link on Bob's bank site, and uses this link as an Image tag. If Bob's bank saves his authorization information in the cookie and the cookie does not expire, Bob will submit the withdrawal form and his cookie when trying to load the image, in this way, the transaction is authorized without Bob's consent.
CSRF is a deputy attack that relies on web browsers and has been obfuscated ). In the preceding example, Bob's web browser is used as the proxy. After being confused, Bob's authorization is mistakenly handed over to Alice for use.
The following are common features of CSRF:
Website hazards caused by user identification
Use the website's trust in user IDs
Spoof the user's browser to send an HTTP request to the target site
The risk lies in web applications that execute certain behaviors through trusted input forms and authenticated users who do not need to be authorized for specific behaviors. Users who have passed the cookie stored in the user's browser for authentication will send an HTTP request to the site that trusts him in the case of full ignorance, and then do the behavior that the user does not want to do.
CSRF attacks using images often appear in online forums because they allow users to publish images instead of using JavaScript.
Preventive Measures
«Snapshot «‹›»
For websites, switching persistent authorization methods (such as cookie or HTTP Authorization) to instantaneous authorization methods (provide hidden fields in each form) will help websites prevent these attacks. A similar method is to include confidential information in the form, and the user-specified code is used for verification outside the cookie.
Another optional method is "dual-commit" cookie. This method only works for Ajax requests, but it can be used as a global correction method without changing a large number of forms. If an authorized cookie is being read by JavaScript code before form post, the cross-domain rule will be applied. If the server needs to include a cookie authorization request in the Post Request body or URL, the request must come from a trusted domain because other domains cannot read the cookie from the trusted domain.
Contrary to common trust ideas, using Post instead of Get cannot provide effective protection. Because JavaScript can use forged POST requests. However, requests that cause "Side effects" on security should always be sent in Post mode. The Post method does not leave a data tail in the web server and proxy server logs, but the Get method does.
Although CSRF is a basic problem for web applications, rather than a user problem, users can protect their accounts on websites that lack secure design: by logging out of the site before browsing other sites or clearing the browser cookies after the browser session ends.
Factors Affecting CSRF
«Topics › & raquo ...... remaining full text>