Coder Perfect

POSTing from a cross-domain form


On this topic, I’ve seen papers and posts all over the place (including on SO), and the general consensus is that the same-origin policy forbids a form POST across domains. Only here has someone suggested that the same-origin principle does not apply to form posts.

I’d want to hear from someone who is more “official” or formal. Is there an RFC that addresses how same-origin affects a form POST, for example?

clarification: I’m not asking if any domain can compose and send a GET or POST. I’d like to know:

In addition, if same-origin does not effect form POSTs, it becomes clearer why anti-forgery tokens are required. 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?

Asked by Brent Arias

Solution #1

Only browser-side programming languages are subject to the same origin rules. So, if you use JavaScript to post to a server other than the origin server, the same origin policy applies, but if you post directly from the form, i.e. the action points to a different server, the same origin policy applies.

<form action="">

If no javascript is used to submit the form, then the same origin policy does not apply.

For further information, go to Wikipedia.

Answered by Suresh Kumar

Solution #2

It’s feasible to create any GET or POST request and deliver it to any server that a victim’s browser may visit. This covers local network devices such as printers and routers.

A CSRF exploit can be built in a variety of ways. The.submit() method can be used to send a simple POST-based CSRF attack. CORS’ use of the xhr.withCredentals feature will be exploited in more complicated attacks, such as cross-site file upload CSRF attacks.

Because the Same-Origin Policy For JavaScript is concerned with JavaScript accessing the server’s response to a client request, CSRF does not violate it. CSRF attacks aren’t interested in the response; instead, they’re interested in the request’s side effect, or state change, such as installing an administrator account or running arbitrary code on the server.

Use one of the strategies mentioned in the OWASP CSRF Prevention Cheat Sheet to ensure that your requests are protected. For more information on CSRF, go to the OWASP CSRF page.

Answered by Mikey

Solution #3

Sending requests to a different url has nothing to do with the same origin policy (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).

However, because these POST requests lack antiforgery tokens, they are disregarded by the other website, making them inefficient. Furthermore, if the JavaScript tries to retrieve the security tokens by sending an AJAX request to the victim url, Same Origin Policy prevents it from accessing the data.

Here’s an example:

And here’s a link to Mozilla’s documentation:

Answered by Mohsenme

Post is based on