CSRF Protection with HTTP GET requests in Rails

Question

I understand that Rails by default doesn't have CSRF protection for HTTP GET requests, because, it claims they are idempotent. However, there is sensitive information that is returned to the user from these GET requests, and, I would't want a malicious site retrieving this information.

What is the best way to protect HTTP GET requests from CSRF in Rails?

When a malicious party does a csrf attack they don't see the results of the request - only the side effects are dangerous — Frederick Cheung, Feb 25 '12 at 18:48
You usually use authentication through cookies for this kind of task — Mikita Belahlazau, Feb 25 '12 at 20:16
@NikitaBeloglazov Even if the authentication is through cookies, the browser normally sends the cookie across to the victim website when it sees a request for the victim's site being made. This is from [the Wikipedia article] (http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics): "If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval." — Aayush Kumar, Feb 26 '12 at 19:37
@FrederickCheung Can you explain a little further how or why the malicious party doesn't or can't see the results of the request? — Aayush Kumar, Feb 26 '12 at 19:40
CSRF is about tricking the victim's browser into making a request, since that's where the credentials are, e.g. by getting them to click on a link / submit a form to http://somebank.com/transfer_money?to=Fred&amount=1000 The response still goes to the user's browser through, not the attacker. — Frederick Cheung, Feb 26 '12 at 19:42
@FrederickCheung I understand that. So, if this request is made through say an ` — Aayush Kumar, Feb 26 '12 at 19:49
Don't think so. Obviously Ajax requests and similar would be disallowed by single origin policy — Frederick Cheung, Feb 26 '12 at 21:43
@Aayush "Even if the data were interpreted as a JavaScript object literal, it could not be accessed by JavaScript running in the browser, since without a variable assignment, object literals are inaccessible." [wiki](https://en.wikipedia.org/wiki/JSONP) — konyak, Oct 02 '15 at 17:27

score 10 · Answer 1 · edited Oct 07 '21 at 05:51

To be able to read the response to a CSRF attack’s request, an attacker would need to get the victim to execute his JavaScript code. And in that case, the access would be restricted by some Same Origin Policy.

Assuming the attacking request is really cross origin, the Same Origin Policy for DOM forbids access via DOM (e. g. when embedded using iframe) and the Cross-Origin Resource Sharing (CORS) regulates cross-origin requests via XMLHttpRequest as follows:

If the request is a simple cross-origin request, i. e. simple method with only simple header fields, then that request will be sent (this is similar to HTML-based CSRF). But accessing a simple cross-origin request’s response depends on whether the response allows resource sharing.

Other cross-origin requests require a so called preflight before the actual request is sent. That request is sent to check whether the server allows requests from the origin the preflight is sent from. And only if the preflight succeeds and the response to the actual request allows resource sharing, the response can be accessed.

So to conclude: Unless your server supports CORS and explicitly allows sharing with any other origin (i. e. Access-Control-Allow-Origin: *), a CSRF response – if the request was allowed at all – won’t be readable by the attacking site.

CSRF Protection with HTTP GET requests in Rails

1 Answers1