7

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?

1
  • 4
    CSRF attacks are less targeted for querying data but rather targeted for requests which trigger actions with side effects, hence the response is less interesting. This means, a simple JavaScript triggered POST form is often the better choice as it’s additionally not dependent on the same-origin policy as XHR requests are.
    – Gumbo
    May 14, 2013 at 21:22

3 Answers 3

8

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.

3
  • Sending the request via XHR may be prevented as well. In case the request does not use a simple method or not only simple headers, a preflight request is used to check whether the actual request is permitted by the server. If that fails, the request will not be send.
    – Gumbo
    May 15, 2013 at 4:45
  • @Gumbo Yes... and a CSRF exploit will not use an XHR for this reason. Was that your point?
    – rook
    May 15, 2013 at 6:17
  • Lot's of reading but all very interesting. Thank you. I didn't know about Same-Origin policies. Because img tags and script tags allow cross origin requests I just kind of assumed everything else did too. May 15, 2013 at 15:18
3

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.

4
  • "stylesheet, but can't programatically access its contents" Can't you get the "computed" style of your own page elements? That would tell you something about the included CSS.
    – curiousguy
    May 15, 2013 at 5:59
  • @curiousguy yes, but I'm saying in the context of a CSRF attempt, i.e. you pick some URL in the target site - which will return sensitive data in some format - and use that URL in the href attribute of a link tag. And it's unlikely that a web service would return sensitive data in CSS format, right? (though I dunno how different browsers would react to malformed CSS, so it's a good point nonetheless)
    – mgibsonbr
    May 15, 2013 at 15:18
  • What should parse as CSS (according to std), exactly? I have really no idea. What does parse as CSS, in real world browsers? What might parse in the future? I am not sure. I am just unsure, and it is unpleasant. The mere fact that I might have to worry about a potential, unlikely, problem is annoying. I like to be able to make security proofs not rely on how unlikely it is that something sensitive might parse as CSS, someday.
    – curiousguy
    May 15, 2013 at 18:30
  • @curiousguy "The mere fact that I might have to worry about a potential, unlikely, problem is annoying" Unfortunatly that's the reality of web application today - too much is left unspecified, too much vary by implementation, too much require trust in the user agent. I agree with you especially on the "future" part, since every new feature browsers introduce usually come with new security holes (either in spec or impl). However, if these specs are corretly implemented, I believe CSS should be safe in this regard...
    – mgibsonbr
    May 15, 2013 at 20:02
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .