6

Same Origin Policy does not prevent origin foo.bar from creating a form with action attribute set to another origin baz.duh and even allows to programmatically submit this form without the user knowing through untrusted events originating via JavaScript just by loading the page. To solve this issue, programmers are forced to use CSRF tokens.

If AJAX requests originating from XMLHttpRequest and canvas objects are subject to Same Origin Policy and not allowed to access the response, why aren't form submissions/XHR requests simply disallowed? What is the reasoning behind this allowance?

I know endpoints accepting the GET request method can be exploited by images as well, but this question is about POST and similar method forms only. Wouldn't the need of CSRF tokens vanish if SOP didn't permit cross-origin form submission? What purpose does cross-origin form submission serve?

Nathan Tuggy
  • 345
  • 1
  • 6
  • 14
user3459110
  • 161
  • 4

1 Answers1

3

The Same Origin Policy protects the client. CSRF tokens protect the server.

SOP prevents malicious site A from accessing cookie credentials held by the client for site B which would otherwise be submitted along with the cross-origin request. See How do web servers enforce the same-origin policy? (short answer: they don't)

The link in the other answer states:

While prevention of cross-origin writes would mitigate entire classes of web security vulnerabilities (CSRF, XSS, etc), the web is a far richer platform because some forms of Cross-Origin Writes are permitted in most cases.

In particular, things like OpenID and quite a lot of credit card processing systems make use of the ability to pass state from one domain's system to another. So banning all cross-origin HTTP would be seriously limiting. Therefore an alternative mechanism is needed. CSRF tokens prove that whatever's sending the HTTP request (remember, not necessarily a browser at all!) got the authorization token from a web page that the server previously emitted.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
pjc50
  • 10,595
  • 1
  • 26
  • 29
  • Wouldn't blocking cross-origin writes in the browser protect the browser users and still support write requests to other origins using the web server as intermediary? For instance, in an online store, when the user submits his/her credit card data to pay for something, instead of POSTing directly to a credit card company web service, the store client code would POST to the its own web server and then the web server would POST to the credit card company. In that way, the user is always sure he/she's only accessing content in the web server he/she trusts. – Alan Evangelista Jul 29 '21 at 14:40
  • 1
    The credit card company doesn't want to entirely trust the web server, though, they want to get the info directly from the browser. Same with OpenID: you *don't* want to send your username and password to the cross-site, only to the openID identity provider. "Go and do something on this other site and come back to me with a token" is an extremely powerful feature to have. – pjc50 Jul 29 '21 at 16:26
  • (authentication tokens are possible by other routes, but if we could get web browsers to support Kerberos other than IE/ActiveDirectory, the world would be a very different place. In-browser authentication is basically dead) – pjc50 Jul 29 '21 at 16:27