Skip to content

Latest commit

 

History

History
95 lines (61 loc) · 5.67 KB

09.1.md

File metadata and controls

95 lines (61 loc) · 5.67 KB
Raw

9.1 CSRF attacks

What is CSRF?

CSRF and XSRF stands for "Cross-site request forgery". It's also known as "one click attack" and "session riding".

So how does CSRF attack work? Basically it's when an attacker trick a trusted user into accessing a website or clicking a URL that transmit malicious requests without the user’s consent to a targeted website. Here's an simple example. Using a few social engineering tricks, an attacker could use the QQ chat software to find a victim and to send a malicious link to the victim targeted for the user's bank website. If the victim logs into their online banking account and does not exit, then click on a link sent from the attacker, then the user's bank account funds could likely to be transferred to the attacker specified account.

When under a CSRF attack, the end-user with an administrator account can threaten the entire Web application.

CSRF principle

The following diagram provides a simple overview of ​​a CSRF attack

Figure 9.1 CSRF attack process.

As can be seen from the figure, to complete a CSRF attack, the victim must complete these two steps:

-1. Log into trusted site A, and store a local Cookie. -2. Without existing site A, access to dangerous link to site B.

See here, the reader may ask : "If I do not meet the above two conditions in any one, it will not be CSRF attacks." Yes, it is true, but you can not guarantee that the following does not happen :

  • You can not guarantee that when you are logged in a site, the site didn't lauch any hidden tabs.
  • You can not guarantee that when you close your browser, your cookies immediately expire and your last session has ended.
  • A trusted high traffic sites doesn't have hidden vulnerabilities that could be exploited with a CSRF attack.

Therefore, it is difficult for a user to visit a website through a link and know that they do not carry out unknown operations for a CSRF attack.

CSRF attacks work mostly because of the process of Web authentication. Although you can guarantee that a request is from a user's browser, you can not guarantee that the user approved the request.

How to prevent CSRF

You might be a little scared after reading the section above. But terror is a good thing. It will force you read on how to prevent vulnerabilities like this from happening to you.

CSRF defenses can be built on the server and client side. A CSRF defense is most effective on the server side.

There are many ways of preventing CSRF attacks are the server side. Most of the defensive stem from from the following two aspects:

  1. Maintaining proper use GET, POST and Cookie.
  2. Include a pseudo-random number with non-GET requests.

In the previous chapter on REST, we saw how most Web applications are based on GET, POST requests, and that cookies where included with the request. We generally design application as follows :

  1. GET is commonly used to view information without changing values.

  2. POST is used in placing orders, change the properties of a resource or perform other tasks.

Then I will use the Go language to illustrate how to restrict access to resources Methods:

mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)

After this treatment, because we define the modifications can only use POST, GET method when it refused to respond to the request, so the above illustration GET method of CSRF attacks can be prevented, but it can all solve the problem yet ? Of course not, because POST also can simulate.

Therefore, we need to implement the second step, the way in non-GET requests to increase the random number, this probably has three ways:

  • For each user generates a unique cookie token, all forms contain the same pseudo-random value, this proposal was the most simple, because the attacker can not get a third party Cookie ( in theory ), so the data in the form will construct fail, but it is easy because the user's Cookie XSS vulnerability because the site had been stolen, so this program must be in the absence of circumstances that XSS security.
  • Each request to use the verification code, this program is perfect, because many enter the verification code, so the user-friendliness is poor, it is not suitable for practical use.
  • A different form contains a different pseudo- random value, we introduce in section 4.4, "How to prevent multiple form submission" is introduced in this scenario, the relevant code reuse to achieve the following :

Generate a random number token

h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))

t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)

Output token

<input type="hidden" name="token" value="{{.}}">

Authentication token

r.ParseForm()
token := r.Form.Get("token")
if token! = "" {
	// Verification token of legitimacy
} Else {
	// Error token does not exist
}

So basically to achieve a secure POST, but maybe you would say if you break the token algorithm does, in accordance with the theory, but in fact crack is basically impossible, because someone has calculated brute force of the string needs about 2 the 11 th time.

Summary

Cross-site request forgery, that CSRF, is a very dangerous Web security threats, it is Web security circles as "sleeping giant", the level of threat which "reputation" can be seen. This section not only for cross-site request forgery itself a brief introduction, also details the reason causing this vulnerability and then put some order to prevent the attack of suggestions, hoping for the reader to write secure Web applications can inspire.

Links

  • [Directory] (preface.md)
  • Previous section: [Security and encryption] (09.0.md)
  • Next section: [Filter inputs] (09.2.md)