181

I've seen articles and posts all over (including SO) on this topic, and the prevailing commentary is that same-origin policy prevents a form POST across domains. The only place I've seen someone suggest that same-origin policy does not apply to form posts, is here.

I'd like to have an answer from a more "official" or formal source. For example, does anyone know the RFC that addresses how same-origin does or does not affect a form POST?

clarification: I am not asking if a GET or POST can be constructed and sent to any domain. I am asking:

  1. if Chrome, IE, or Firefox will allow content from domain 'Y' to send a POST to domain 'X'
  2. if the server receiving the POST will actually see any form values at all. I say this because the majority of online discussion records testers saying the server received the post, but the form values were all empty / stripped out.
  3. What official document (i.e. RFC) explains what the expected behavior is (regardless of what the browsers have currently implemented).

Incidentally, if same-origin does not affect form POSTs - then it makes it somewhat more obvious of why anti-forgery tokens are necessary. I say "somewhat" because it seems too easy to believe that an attacker could simply issue an HTTP GET to retrieve a form containing the anti-forgery token, and then make an illicit POST which contains that same token. Comments?

Brent Arias
  • 29,277
  • 40
  • 133
  • 234
  • Yes, an attacker could do that... with an ordinary web browser. – Michael Hampton Dec 27 '13 at 10:14
  • Perhaps there are no RFCs for the same reason why there are no RFCs that say: "don't post your password on your website". Web standards are only required when multiple parties must work together to achieve something: the same origin policy is more of a complex set of "security best practices" that prevent users from getting hacked. – Ciro Santilli OurBigBook.com Jul 03 '14 at 11:35
  • @Ciro Please say explicitly. The rules for cross-posting to other sites do not affect affect multiple parties. No need the foggy parlance. – Little Alien Sep 27 '16 at 10:30

3 Answers3

204

The same origin policy is applicable only for browser side programming languages. So if you try to post to a different server than the origin server using JavaScript, then the same origin policy comes into play but if you post directly from the form i.e. the action points to a different server like:

<form action="http://someotherserver.com">

and there is no javascript involved in posting the form, then the same origin policy is not applicable.

See wikipedia for more information

Suresh Kumar
  • 11,241
  • 9
  • 44
  • 54
  • 21
    Sorry to drag up an old question, what would happen if the action was changed using JS but then the form was posted using a button? Would that allow for a successful cross-domain post? – Chris Jul 04 '13 at 15:47
  • AFAIK it shouldn't be a problem but I haven't tried it myself. Would be interesting to find out. – Suresh Kumar Jul 05 '13 at 03:50
  • 3
    I'm of the same thought. I actually had worries about security, some third party JS/virus changing the action to post the form somewhere malicious, but realised this could be done on any payment receiving form cross domain or not and the outcome would be the same. Lesson here really: check any third party JS files ;) – Chris Jul 05 '13 at 09:38
  • 26
    In short: YES, cross-domain POSTing is allowed. – Christian Davén Apr 15 '14 at 13:59
  • I don't think it's really about javascript or not, rather if you want your page to end up on the target domain after the post. If not you need to look at CORS or mod_proxy like solutions. – user1255162 Jun 25 '14 at 16:21
  • 22
    -1 for: Same origin policy has nothing to do with sending request to another url (different protocol or domain or port), it is all about restricting access to (reading) response data from another url (and thereby preventing javascript to update document with forms that have security tokens from other url). – Mohsenme May 07 '15 at 22:46
  • 3
    For anyone coming here in 2021, it is worth noting that Chrome will now block some cookies on a form post unless they are set with SameSite=None and Secure=true https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html – waternova Jun 23 '21 at 17:18
  • @waternova From Firefox version 69: this feature is behind `network.cookie.sameSite.laxByDefault` preferences in about:config – Alex78191 Oct 15 '21 at 10:39
  • -1 Suggesting to remove the incorrect dependency on "browser language" vs. "browser". It would be nice to clarify if `SameSite=None;Secure` cookies are sent across origin with form posts (in contravention to XHR requiring `withCredentials` and causing a pre-flight request). – eel ghEEz Mar 09 '22 at 14:50
51

It is possible to build an arbitrary GET or POST request and send it to any server accessible to a victims browser. This includes devices on your local network, such as Printers and Routers.

There are many ways of building a CSRF exploit. A simple POST based CSRF attack can be sent using .submit() method. More complex attacks, such as cross-site file upload CSRF attacks will exploit CORS use of the xhr.withCredentals behavior.

CSRF does not violate the Same-Origin Policy For JavaScript because the SOP is concerned with JavaScript reading the server's response to a clients request. CSRF attacks don't care about the response, they care about a side-effect, or state change produced by the request, such as adding an administrative user or executing arbitrary code on the server.

Make sure your requests are protected using one of the methods described in the OWASP CSRF Prevention Cheat Sheet. For more information about CSRF consult the OWASP page on CSRF.

Mikey
  • 774
  • 4
  • 6
  • I have updated my question to clarify. Also, the WordPress link you gave involves exploits that were initiated from within same-origin X, rather than initiated from cross-domain Y...so it isn't the right scenario from what I see. – Brent Arias Jul 11 '12 at 02:05
  • @Brent Arias yes, what you are describing in 1 and 2 is exactly equal to what a CSRF attack performs, perhaps you should try executing one of the CSRF exploits provided and sniffing the traffic. I have updated my post, you should read every link provided because it will answer these questions accurately. The point of a "cross-site request forgery" (CSRF) attack is the request originates from another domain, all exploits provided fully meet this fundamental requirement. – Mikey Jul 11 '12 at 03:00
20

Same origin policy has nothing to do with sending request to another url (different protocol or domain or port).

It is all about restricting access to (reading) response data from another url. So JavaScript code within a page can post to arbitrary domain or submit forms within that page to anywhere (unless the form is in an iframe with different url).

But what makes these POST requests inefficient is that these requests lack antiforgery tokens, so are ignored by the other url. Moreover, if the JavaScript tries to get that security tokens, by sending AJAX request to the victim url, it is prevented to access that data by Same Origin Policy.

A good example: here

And a good documentation from Mozilla: here

Community
  • 1
  • 1
Mohsenme
  • 1,012
  • 10
  • 20