Rails Security Guide "two"

You can go on to the previous chapter to see:

Three Cross-site Reference forgery (CSRF)

-This attack method contains either malicious code or a link to a user-trusted authenticated Web application page. If the session does not expire, an attacker could execute an unauthorized command.

In the session chapter, you've learned that most rails applications use a cookie based session. Either they store a session ID in the cookie, the server has a session hash, or the entire session hash is on the client. When you send a request to a domain name, if you can find a cookie for this domain name, the browser automatically comes with this cookie. However, the problem is that requests from sites with different domain names will also send this cookie. Look at this example:

1.BOB read a message board and an HTML tag made by hacker. This element refers to a command in a Bob's project management application, not a picture.

2.

The 3.BOB session was still alive in www.webapp.com, as he had just left a few minutes before logging off.

4. When the browser discovers this IMG tag, he tries to load the image from Www.webapp.com, as mentioned earlier, he will send a cookie with a valid session ID (Bob's cookie, he just landed www.webapp.com).

5. The Web application located in www.webapp.com validates the user information for the session hash and deletes the project with ID one. It then returned a result that was unexpected to the browser, so it did not display an image.

6.Bob didn't notice the attack, but some days later, he found that project ID one left him.

It is important to note that the actual production of the image or link does not necessarily have to be located in the Web application's domain, it can be anywhere-in a forum, blog post or email.

CSRF is an important security problem that cannot be neglected.

3.1 CSRF Countermeasures

-1th, follow the standard of the consortium, use get and post correctly, 2nd, use a security token in Non-get request will keep you away from CSRF.

The HTTP protocol provides two types of requests-get and post (and others, but not supported by most browsers), and the World Wide Web Consortium provides a list of choices for HTTP GET or post:

Use Get if:

This interaction is more like a problem, it is a safe operation, such as query, read operation, or lookup

Use POST if:

This interaction more like an order, or

This interaction changes the state of the resource according to the user's expectation, such as subscribing to a service.

The user is responsible for the results produced by this interaction.

If your application is restful, you may use an extra HTTP verb, such as put, DELETE. Today, however, most browsers do not support them, only to get and POST. Rails uses a hidden _method to deal with this hurdle (as I said in the last paragraph of this article http://blackanger.blog.51cto.com/140924/108678 quote DHH).

The validation method in a controller ensures that specific actions do not overuse get.