Are CSRF Attacks Really Blind

Question

I'm new to CSRF attacks but don't see how they are always blind.

Let's say we are dealing with a site where the asset we need to protect is the HTTP response. Something like one's medical history. According to what I've read one shouldn't need to protect GET requests even though the response to these requests may contain sensitive information.

What prevents an attacker from making a CSRF Ajax request and then sending the response from that request as a POST or GET to another server?

Answer 1

The Same-Origin Policy makes it impossible for JavaScript on A.com to read content from B.com. However, Same-Origin Policy does not prevent JavaScript or HTML on A.com from sending an arbitrary request to B.com. In order to prevent this, you need a method of CSRF Prevention, such as a secret token which would not work if the system wasn't blind.

The point of CSRF is that it incurs a useful side-effect, like changing a user's password or adding an administrative account. Even if CSRF wasn't blind, (due to some magic, or perhaps a misconfigured CORS or crossdomain.xml rule-set) it wouldn't matter as the response would probably be discarded, all that matters is a useful side-effect.

It is very easy to send GET and POST requests cross-domain, if a GET request incurs a side-effect, then it is vulnerable to CSRF. A good example of this is a PHP application that uses $_REQUEST for all inputs.

Answer 2

Yes, they are blind. The same-origin policy prevents pages hosted in one domain using one protocol [and sometimes also port] to making arbitrary requests to a different domain/protocol. So, one attacker would not be able to make a "CSRF Ajax request" unless your server supports CORS. What makes CSRF attacks possible at all are the exceptions for the same-origin policy, i.e. the types of request any website is allowed to make to any host.

Most exceptions to the same-origin policy however does not allow you to do anything useful (including read) with the response:

• You can set an image's src to another domain, but the response will either render correctly as an image for the user to see, or render nothing at all;
• You can set a script's src to another domain, but it will either run or cause a syntax error or similar;
• You can link to an external stylesheet, but can't programatically access its contents;
• You can include another page in a frame ou iframe, but can't access its DOM contents due to the same-origin policy; etc.

That's why, as others already pointed out, the response is not what's interesting for an attacker, but the side-effects the request can have.

Answer 3

First of all, CSRF attacks do not require any JavaScript at all. You can forge arbitrary requests with pure HTML to send arbitrary GET or POST requests via simple images or simple forms.

JavaScript would only be helpful to automatically send the latter forms as are not send automatically like a request for an image would. But you could also style the form’s submit button to span the whole page and make it transparent so that it won’t be seen by the user but if he clicks somewhere on the page, the form will be send.

In most cases, sending the forged request is sufficient for the attacker as the intention is to simply trigger an action in behalf and session context of the victim. For this a simple HTML form is sufficient.

But with JavaScript, the Same-Origin Policy comes in play, which makes it much more difficult. The origin is determined on the document’s URI (i.e., the scheme, host, and port). Only if the origin of two documents or resources are identical, the two documents/resources are same-origin. If they are not same-origin, the Same-Origin Policy basically disallows any XHR requests or direct access via DOM (e.g. frames).

With the second version of XMLHttpRequest (XHR), the technology used with Ajax, cross-origin requests were permitted under certain circumstances defined in Cross-Origin Resource Sharing. The basic rules are that simple cross-origin requests are allowed while other require a preflight request before the actual request. That preflight is used to determine whether the server would accept the actual request. Only if that preflight request succeeds, the actual request is send.

However, even if it’s only a simple request and the request succeeds, the server may still disallow the browser to make the response available to JavaScript, again via certain response header fields defined in CORS.

As for CSRF attacks, especially the latter type of cross-origin requests are worthy as those would contain user credentials like HTTP authentication information, cookies, etc., which would be required to trigger privileged actions on the server. But unless the resource allows such cross-origin requests, the browser won’t allow JavaScript to send these.

So the conclusion is:

• CSRF does not require JavaScript, however it makes automatic exploitation much easier.
• Simple HTML based request forgery is much more promising due to the lack of conformance with the Same-Origin Policy, which JavaScript requires.
• Reading the response is only possible with JavaScript but it requires the resource to allow it, especially if user credentials are required.