4

I think I understand what the same-origin policy is. It says that scripts and AJAX requests must come from the same origin, meaning they must have the same protocol, host, domain and port.

What I don't understand is what it actually protects against. For example, say that we have two sites: attacker.com and bank.com. I get that attacker.com can't have scripts or AJAX requests access bank.com. But...

  1. You could use cURL to make any request you want to bank.com.

  2. You could use the browser to make any sort of GET requests you want to bank.com

Given these things, what does the same-origin policy really protect against?

Adam Zerner
  • 17,797
  • 15
  • 90
  • 156
  • I wrote [this story](https://medium.com/@adamzerner/web-security-a-story-8bba0587b34d) to explain further. – Adam Zerner Mar 16 '15 at 19:19
  • It does not say that. It prevents [direct access to resources via scripting](http://stackoverflow.com/a/28762923/413180) that are owned by different Origins without them opting in. [It does not prevent AJAX requests from being made, only their responses read.](http://stackoverflow.com/a/27781597/413180) – SilverlightFox Mar 17 '15 at 13:57

1 Answers1

5

There is no security issue when it comes to you making your own requests to bank.com, using cURL or your browser. There is no attacker in these scenarios, just you and the bank.

The issue comes into play when you visit attacker.com and it, unbeknownst to you, makes a request to bank.com using your browser, which may be logged in to bank.com.

The same-origin policy prevents the owner of attacker.com from making requests to bank.com using your browser.

Paul
  • 139,544
  • 27
  • 275
  • 264
  • > There is no security issue when it comes to you making your own requests to bank.com, using cURL or your browser. Is that because bank.com presumably requires authentication? – Adam Zerner Mar 16 '15 at 15:25
  • Wouldn't attacker.com need access some sort of session_id, presumably stored your bank.com cookies? Ie. if there was no same-origin policy, it still wouldn't be able to get your info without that session_id. – Adam Zerner Mar 16 '15 at 15:27
  • @AdamZerner Yes, if you're making your own requests, then there is no attacker invovled, just you and the bank. – Paul Mar 16 '15 at 15:27
  • 2
    @AdamZerner Cookies are stored in the browser and sent automatically for all requests to the domains that they are valid on. So the idea is that `attacker.com` doesn't need to know your session_id, because it is stored in your browser already and they are using your browser to make the request. That is why CSRF attacks work as well. – Paul Mar 16 '15 at 15:29
  • Oh, so if attacker.com make a request to bank.com, it'd send the bank.com cookies? And the attack.com cookies? – Adam Zerner Mar 16 '15 at 15:31
  • @AdamZerner It would only send the bank.com cookies to bank.com – Paul Mar 16 '15 at 15:34
  • 2
    @AdamZerner Supposer attacker.com has some code in place that requests bank.com, checks if the user is logged in, and if the user is logged in, it navigates to the transfers page and initiates a transfer for all the user's money to the attackers account. Without the same-origin policy, the attacker could do all that stuff, since it could make all those requests to bank.com, using the user's browser, which has the user's session cookie for bank.com – Paul Mar 16 '15 at 15:37