Why you shouldn’t rely on ajax’s same origin policy

XmlHttpRequests (or “ajax“) is generally considered to be safe because it is restricted by the “same origin” policy, but that isn’t entirely correct. Consider the following: an ajax-call, like all http communication, consists of a request and a response. For read-operations the response is needed, for write-operations … that ain’t necessarily so!

So how can a “hacker” send a request for such a write-operation and have it executed (which amounts to  “cross site request forgery” actually)? There’s a number of  possibilities:

  1. Execute a GET-request by including it in the attack-site html as the src of a script, css or img tag, for all of which the same origin-policy does not apply.
  2. Using JavaScript to create a form, populate it and POST it, the same-origin policy does not apply to forms being posted.
  3. Just do a normal XHR-request, the same-origin policy applies, but some top-notch browsers will execute the request and just ignore the response (is that a bug or a feature?)

Conclusion: if you want to do anything more than read-requests on the same domain, you really-really-really have to protect your resources against CSRF using one of the techniques that are described in this wonderful OWASP CSRF cheat-sheet.

Leave a Reply

Your email address will not be published. Required fields are marked *