How is the same origin policy causing my PoC to fail when I don't need to read return data?

Question

I'm performing an authorized vulnerability analysis on a custom web service and have discovered a CSRF vulnerability.

Due to there not being form tokens coupled with the service not checking for the origin header I believed I could forge requests via AJAX POSTs from an "infected" proof of concept page.

Due to the way the web server maintains state it requires a series of six sequential POSTs to complete my attack. Here comes the problem:

My first PoC involved creating six simple html pages (each with one form) that I would load and submit one by one, in order, to validate my assumptions. This worked fine so I converted these form actions to sequential AJAX POSTs. My attack stopped working at this point. I compared the actual HTTP requests for both content and order - all of the application layer data matches.

I became suspicious of the same origin policy for some reason despite NOT needing to read any return data so I started Chrome with the --disable-web-security option (to disable the policy), tried my attack again, and this time it succeeded. It seems the same origin policy is somehow preventing my attack, but I have no idea why since I don't need to read any returned data. What am I not understanding? What have I not thought about? Is there any way to accomplish what I want to do?

Answer 1

There is no reason that this should not work as long as third party cookies are enabled in your browser.

HTML form POSTs can be used, or in the case that the forms are a multi-stage process then this will be more useful to run as XHR requests as your attacking page can then control the requests and issue them in turn - just as your are doing.

Make sure that you are setting withCredentials on your AJAX requests.

In jQuery this is done like the following

$.ajax({
  type: "POST",
    url: 'http://www.example.com/Controller/Action',
    data: 'foo=bar',
    async: true,
    xhrFields: {
      withCredentials: true
   }
});

Other answers suggest that using withCredentials means that a CORS pre-flight request is sent to the resource instead of the intended GET or POST. This is not the case as long as the request is a "simple request". If your exploit worked with HTML forms then the correct AJAX equivalent would be a simple request, so check that all you code is correct.

(note the following quote is from the original linked page to CORS above http://www.html5rocks.com/en/tutorials/cors/, however, this is now a 404, therefore, the above link has been changed to here.)

Cross-origin requests come in two flavors:

• simple requests
• "not-so-simple requests" (a term I just made up)

Simple requests are requests that meet the following criteria:

• HTTP Method matches (case-sensitive) one of:

• HEAD

• GET

  • POST

• HTTP Headers matches (case-insensitive):

  • Accept
  • Accept-Language
  • Content-Language

• Last-Event-ID

• Content-Type, but only if the value is one of:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Simple requests are characterized as such because they can already be made from a browser without using CORS.

This is actually mentioned in the CORS specification and indicates that CORS does not actually add security, it only enables cross-domain communication when both the client and server opt into the specification. If both parties do not opt in (such as in a CSRF attack where the victim site does not wish to be communicated to in this fashion), then the browser will act in a similar way to pre-CORS. i.e. cookies will be sent although the response will not be readable:

resources conforming to this specification must always be prepared to expect simple cross-origin requests with credentials. Because of this, resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery (CSRF) by requiring the inclusion of an unguessable token in the explicitly provided content of the request.

Back to your question:

I compared the actual HTTP requests for both content and order - all of the application layer data matches.

I suggest that you use an intercepting proxy such as Burp or Fiddler2 to verify the requests. Checking the requests from inside the browser is not an accurate way of verifying this because the requests viewed in Chrome are subject to be interpreted from the Origin of the page they are issued from and if the Origin doesn't see the response due to the Same Origin Policy, then neither will you in dev tools. Chrome informs you of this via the “CAUTION: provisional headers are shown” message.

For example, the following is the same request as shown in Chrome dev tools and then in Burp. Notice how only the external tool shows the cookies.

I've tested this behaviour with Chrome 38, Firefox 32 and Internet Explorer 11 on Windows 7 x64, and it is consistent across browsers (however, make sure 3rd party cookies are enabled in settings) so this is further indication that this behaviour complies to current standards.

So my advice is to double check your code and requests using an intercepting proxy. Maybe post them on here for another pair of eyes to check as if it is working one way but not the other then there must be a mistake somewhere because the requests will not be the same.

Also, make sure that your code isn't exiting early due to the error returned because of Same Origin Policy violation.

Important note: A point was just made in this comment. Sometimes it may also be possible to trigger a simple request with the following Content-Type: text/plain; application/json. Therefore if application/json is checked for in server-side code, then these checks must be robust enough to ensure it is only this content type, or else another more robust method of anti-CSRF checking must be employed (e.g. un-guessable, session specific tokens within the POST body or header).

Answer 2

Try catching the error with nothing. The SOP error does raise an exception, which does stop your script execution. If you instead Catch the error, the request will be fired away, your response will be filtered, a exception is thrown that will catched, and your script will continue with the next request.

So basically, now it works like this:

attackstep1() << script stop here due to a exception, thus only step1 of attack is performed
attackstep2()
attackstep3()
.....

Instead, try something like this:

try {
attackstep1()
}
Catch(e) {}
try {
attackstep2()
}
Catch(e) {}
try {
attackstep3()
}
Catch(e) {}
try {
....
}
Catch(e) {}

This will ignore the SOP permission error and continue script execution. Note that you will not get access to any Resources that the protected resource returns.

Answer 3

The error message you got is because the Cross-origin resource sharing (CORS) is not enabled on the server you try to attack. So all your AJAX requests will not be accepted by the server that host the web services.

So if you enable CORS on your target server, the server will accept your AJAX requests. Do not use AJAX since if CORS is not enabled your request will be denied. You can use curl a nice command line tools that can call web services.