Is CSRF protection for side effect free GET requests needed?

1
votes

I'm developing a web application in which all dynamic content is retrieved as JSON with Ajax requests. I'm considering whether I should protect GET API calls from being invoked from different origins?

GET requests do not modify state and a common wisdom is that they do not require CSRF protection. But I wonder if there are no corner cases in which browser leaks the result of such requests to a different origin site?

For example, if a different origin site GETs /users/emails as script, css or img, is it possible that a browser would leak resulting json to the calling site (for example via javascript onerror handler)?

Do Browsers give strong enough guarantees that a content of a cross origin JSON response won't be leaked? Do you think protecting GET request against cross origin calls makes sense or is it overkill?

3
securitycsrf
Are all requests guaranteed to be side effect free, or do you also have Ajax requests that modify the state? Are such planned? If any of this is the case, I'd guard them anyway, if only to unify the API. – Creshal
Yes, the application uses POST, PUT and DELETE requests that modify the state and these obviously need CSRF protection. – Jan Wrobel

3 Answers

1
votes

You have nailed a corner case and yet highly relevant issue. Indeed, there is this possibility, and it's called JSON Inclusion or Cross Site Scripting Inclusion or Javascript Inclusion, depending on who you refer to. The attack is, basically, doing a on an evil site, and then accessing the results via javascript once the js engine has parsed it.

The short story is that ALL your JSON responses have to be contained in an Object, not an Array or JSONP (so: {...}) and for better measure you should start all responses with a prefix (while(1), for(;;) or a parser breaker). Look at facebook's or google's JSON responses to have a live example. Or, you can make your URLs unguessable by using a CSRF protection - both approach works.

0
votes

No:

This is not a CSRF issue, as long as you're returning pure JSON and your GET's are side affect free, it DOES NOT have to be csrf protected.

what Paradoxengine mentioned is another vulnerabilty: if you are using JSONP it is possible for an attacker to read the JSON sent to an authenticated user. Users of very old browsers (IE 5.5) can also be attacked in this way even using regular JSON.

0
votes

You can send requests to a different domain (which is what CSRF attacks do), but you can't read the responses.

I learn this in another stack overflow question from here It seems like I understand CSRF incorrectly? hope this help you understand the question.