So far all I can see is that if site A using JavaScript to send a request to site B, the cookies shouldn’t be sent to site B. This prevents the user from being logged in so any information returned would be public. That just leaves the access to intranet resources problem which seems to be the best explanation.

ddoctor – you’re completely right but I was thinking more in terms of what standards define rather than best practices etc. In other words, not what might go wrong if people write insecure code but what vulnerabilities would cross-site XmlHttpRequests open up in browsers if it were part of a specification.

Basically what Philip said. Hacker x sneaks JavaScript onto some popular site that displays user-generated content and doesn’t whitelist properly. JavaScript creates a small iFrame to load gmail.com and like most people, you don’t normally log out for convenience. Without same-origin the hacker would have access to your entire mail account :)

iFrames aren’t really AJAX requests though. JSON should work just fine, because it’s doing a HTTP request to site B and then translating it into JavaScript on the client side, completely routing around the same-origin policy. This, of course, leads to other variations of XSS attacks.
http://en.wikipedia.org/wiki/JSON#Cross-site_request_forgery

I know that you know this argument, because you gave it to me when I was working with the RedDot integration. :)

Remember that a request from a client cannot be trusted, so you should never blindly do /anything/ the client tells you to – i.e. no simple proxies. Doing this can directly compromise the server.

The other thing to remember is that 3rd-party services are also untrusted. Sanitize information from them, as you would user input. You wouldn’t rely on client-side validation for a form – same goes when validating external sources.

Client-side is an untrusted world, and should be contained. A web page should only be trusted to make AJAX requests against the web server it came from, otherwise if it is compromised (e.g. via a XSS javascript injection attack) it can send sensitive information to another site (e.g. a login cookie, or more sensitive information it could get via a XMLHttpRequest). Cross-domain scripting controls are a simple measure to prevent this.

Security aside, architecturally, system integration should generally not be done in a GUI tier. Aggregate your data sources and functionality at the server and present that as a unified interface to the user. From the user’s perspective, they are interfacing with a single service – the client tier should share this perspective.

Option 1 without AC would allow evil site A read private content from site B using the login credentials of the user for site B.