Final Thoughts on the Same-Origin Policy
Before we move on to discussing some browser-side attack techniques, we should probably clarify that there are lots of ways to make cross-origin calls other than the ones we’ve talked about here. Technically, all script code needs to make a cross-origin request is a way for it to send an HTTP GET message, and there are dozens of ways to do this. The catch is that just being able to send a cross-origin request usually isn’t useful unless you’re able to read the response. But the operative word here is “usually.”
If an attacker is trying to steal your private information like your bank account number, and he can’t get the bank to send it to him directly, maybe he can take an alternative tack and trick you into sending it to him. And in this case, you won’t even need to wire a money order to someone claiming to be the Prime Minister of Nigeria—all you’ll have to do is visit a vulnerable web site, and your browser will silently and automatically send the attacker the information he’s looking for. In the next chapter, we’ll look at the most popular browser-based attacks designed to bypass the same-origin policy: cross-site scripting and cross-site request forgery.
Sometimes it may seem as if the same-origin policy exists only to make programming more difficult, but the truth is that it’s there to protect you and your users. If you have a great idea for a cross-origin application and you want to bend the rules a little, follow these steps to do it in the safest possible way.
Use caution when embedding <script> elements in your application that point to third-party sites. If an attacker were able to gain access to any of these scripts, your application would be compromised and your users’ personal data could be stolen.
Don’t use the JavaScript “eval” function to parse JSON strings into script objects. The parseJSON function is a much safer alternative, although it’s only available in newer versions of web browsers.
If you can’t use parseJSON because your users may be on older browsers, consider using an open JavaScript library like jQuery to do your JSON parsing.
Using third-party JSONP is essentially the same thing as using third-party <script> elements. If you wouldn’t trust the site to give you JavaScript, you shouldn’t trust it enough to give you JSONP.
Don’t use JSONP to send sensitive data. Since JSONP is valid JavaScript, it’s not protected by the same-origin policy.
Lowering a page’s document.domain value increases the number of sites that can read data from that page, but this means that it also increases the number of sites that can steal data from that page. Also be aware that in most browsers, once you lower a page’s document.domain value, you can’t change it back again.
When you’re defining cross-origin policy files for Flash and Silverlight, it’s safer to list specific sites that you want to grant access to than it is to use wildcards like *.com. It’s really only appropriate to allow wildcard access when your site doesn’t have any sensitive data.
Consider splitting your site into separate subdomains for authenticated and anonymous use. This will let you create an open cross-origin policy file for the anonymous portion, and put tighter controls on the authenticated content.
You can use the cross-origin resource sharing (CORS) feature of XMLHttpRequest without worry, as long as you don’t allow credentialed requests.
XDomainRequest is much safer to use than other alternatives, but remember that its functionality is limited so that it can never send cookies, and that it’s only available in Internet Explorer versions 8 and later.
Defining the same-origin policy
Which request components define an origin
How different browsers define origin in different ways
Why we need the same-origin policy: taking a look at a world without it
Exceptions to the same-origin policy
The HTML <script> element
JSON and JSONP
iframes and JavaScript’s document.domain property
Adobe Flash cross-domain policy file
Microsoft Silverlight client access policy file
XMLHttpRequest (Ajax) and cross-origin resource sharing (CORS)
Internet Explorer’s XDomainRequest