I suppose I reversed your suggestion, but the opposite still sounds very suspect to me. I admit that a cursory glance doesn’t reveal such an obvious vulnerability as the reverse case, but your approach does nothing to improve security and would actually introduce the potential for entirely new classes of vulnerabilities.

From a practical standpoint, my first question is how you’d actually register the cross-origin exception? You can’t include the script directly, because it would execute in the context of the requesting origin. So, I would think that one site would need to have a frame executing the exception script on the other site. That seems like a very circuitous route, and the beginning of an administrative and auditing nightmare.

Given the current prevalence of trivial web vulnerabilities, consider how much worse things would get if developers could scatter origin exceptions throughout their code. Imagine trying to identify origin bypasses in a moderate-size application when they’re embedded in JavaScript spread out across all the code in a site. I just can’t see how a situation like this would ever be preferable to a policy file that’s easy to identify and audit.

Also, how long should the exception be valid? This is something that’s easy to specify in a policy file, but how would you handle it in your approach? Would you add a DOM properties or is it just valid for the duration of the browsing session? And how does a site refresh a bad exception when it’s explicitly initiated by the foreign origin? With these policy exceptions spread out it seems like stale and/or overly-permissive exceptions would become a prime target of attack.

Finally, I’m not comfortable with the all-or-nothing approach of opening one site to requests from another site. It effectively means accepting the entire attack surface of a remote site as your own. In the case of public, general-use widgets, that’s basically the entire Internet.

Now, on to your question about my origin policy ramblings. The first thing to consider is that not all XSS vulnerabilities are quite so straight-forward. There are often limits on the injected text size, location, and format. (Hence the value of things like the XSS cheat-sheet.) So, adding restrictions on external includes and navigation could often make an exploit impractical.

More generally, however, the policy I proposed could white-list any requests to other origins, even user initiated clicks. Such a strict approach is probably not practical for all sites, but it would be a good idea for something like a banking application (and I’ve looked at enough of those to consider it a feasible solution in such cases).

What I suggested was that if evil.com added myFinancialInstitution.com to document.domain, then myFinancialInstitution.com should have access to evil.com, but not the other way, meaning evil.com should not have access to myFinancialInstitution.com . Does this cause any security problem?

Also, about your server-defined, browser-enforced security policy idea, I see how limiting inbound requests can prevent cross-site request forgery. But limiting outbound requests doesn’t really prevent cross-site scripting because injected JavaScript can simply change links on the page to go to a URL at evil.com with whatever info it wants to smuggle out included in the URL, so that when the user clicks on a link, evil.com gets the info.

To illustrate, let’s walk through a hypothetical scenario. Assume that I browse to evil.com with the current same origin policy. Now, there are ways that evil.com can interact with other sites, such as including scripts, stylesheets, or images. However, scripts on evil.com are limited in how they can interact with this data; they can’t make HTTP posts; and included stylesheets and scripts must be properly formatted. Also, any script retrieved from another location is executed in the context of the requesting origin, not the serving location. So, it’s possible to get code in and data exfiltrated through URLs, but interaction with other sites is still fairly limited.

Now let’s consider the same scenario with your suggestion, where scripts on evil.com can add domains as valid origins. For example, a script on evil.com could add myFinancialInstitution.com to document.domain, then script out a funds transfer to some offshore account. Assuming I’m currently logged in to myFinancialInstitution.com, my session cookie would be passed and the transfer would succeed. And speaking of cookies, this scenario would expose all cookies for reading and writing by any arbitrary site. One could imagine a malicious script that enumerates through a list of sensitive domains, checks for active session cookies, then attempts to perform some illicit activity.

In case the dangers of this proposal are still unclear, I suggest rereading the original same-origin post at http://taossa.com/index.php/2007/02/08/same-origin-policy/ . Really though, I think your response only further emphasizes why a good origin policy needs to separate the code from the policy itself. With the current same-origin policy, a single vulnerability undermines the security of an entire site. By isolating the policy, sites can provide some mitigation against such vulnerabilities.

Anyway, it’s always good to see developers curious about security, and hopefully you find the information helpful.

“Worse yet, the rise of AJAX and mash-ups seems to have turned same-origin into something developers are trying to break.”

I am a programmer, not a security guy. I see same-origin mostly as a huge nuisance to be gotten around. And using a policy file, as suggested here, doesn’t solve the problem because programmers providing widgets to be added to other people’s web pages can’t expect those people to go through the trouble of modifying a policy file.

For this issue to be resolved, security people have to recognize that once JavaScript is injected into a page, the creator of that JavaScript has full control over that page and all security attempts to restrict that JavaScript are pointless. Any restrictions on what JavaScript can access from within a web page can be gotten around by having that JavaScript go through a server to get access. So limiting XmlHttpRequest with the same-origin policy makes no sense at all because JavaScript can always add a “script” element to the DOM to load another JavaScript file from a server which can itself load whatever XmlHttpRequest would have loaded and then pass it back in a JavaScript file. Similarly, if JavaScript loaded from xyz.com into some page in another domain wants to communicate with a frame loaded from from xyz.com, then it can do so through the server. The fact that one can work around these restrictions means that the security value of these restrictions is zero. But the nuisance value and the performance hit is big enough to make these restrictions a big negative for web development.

The sensible solution is to allow document.domain to be an unrestricted list of domains. So I should be able to say:

document.domain += “,xyz.com”;

And then JavaScript in pages from xyz.com should have access to this page just as other pages in the same origin do. And the same-origin restriction on XmlHttpRequest should simply be dropped. This solution recognizes the fact that it is hopeless to try to restrict JavaScript that has made it into a page. And given this, it makes sense to make things easy for JavaScript and HTML widget programmers.

First off, no one has to apologize for long posts here. We’re not exactly known for our brevity (ahem… John). Anyway, you added a lot of interesting points, so I figured I’d respond in order.

1) I’m still trying to decide on content restrictions. My first take is that they’re integrated into the page and they feel a bit too complex, which worries me a bit, but I can’t frame it as more than that yet. More concretely, content restrictions don’t prevent CSRF attacks (http://ha.ckers.org/blog/20060626/content-restrictions-and-script-keys/), which would be addressed in my suggested policy. They also don’t provide as fine-grained control over loosening origin restrictions. That said, I see the potential and am still mulling over the concept. In particular, content restrictions seem more appropriate than my suggestion for intra-site activity, so perhaps the right idea is a combination of the two?

2) It looks like we’re both on the same page with cryptographic validation. Originator validation can be very handy and at this point there’s little reason not to do it.

3) Your protection solution certainly guarantees same-origin sandboxing, and works with existing browsers. (Oddly enough, I’ve been using MOZ_NO_REMOTE=1 with multiple profiles to make cross-session exploit testing easier.) I’m adding your approach to my list and will be covering it in a future discussion. However, I doubt it’s a long-term solution because it’s just not reasonable for the average user. Also, it doesn’t address the need to allow cross-site communication where appropriate. I was targeting my proposal at a balance between security and functionality. In my experience developers want their jobs easy and most users want it even easier, but I might have missed my mark.

4) Yeah, I pretty much agree on all points here.

5) You and I seem to be in the same camp here. I’m really bothered by the “throw a device in front of everything” mentality. TCP/IP firewalls work because the rules are relatively simple, which is possible because they don’t dig into the application layer. I expect WAFs to never work very well because they’re the exact opposite of TCP/IP firewalls; WAFs seem intent on trying to duplicate the application logic in the firewall. That’s a role better served by a programming framework.

I hope I didn’t come across like I was suggesting embedding a WAF in the browser. I was intentionally trying to keep the ruleset simple, and not try to dig into the application logic. In the end I think it comes down to encouraging a server-side function segmentation and letting the originator provide more fine-grained control over the restrictions enforced by the existing same-origin policy.

6) You’re totally right that proper input handling can address XSS, and that’s always the right approach. I just figure an extra measure of policy at the browser can help mitigate client-targeted vulnerabilities that slip through the cracks.

1) Both content-restrictions and httpOnly could be extensions to browsers. I don’t see your technique as strong over content-restrictions. httpOnly, however, has problems.

2) SSL Certs do NOT cost $20 (or even NameCheap’s $16). WWW.StartCom.ORG has certs available for free. The catch? The certificate for their CA is only default in Mozilla products (including Firefox) and KDE’s Konquerer. CAcert.ORG may also get included in Mozilla’s products and it is also free. It is my opinion that IE7 should immediate include both as well… and developers should start signing applications, containers, objects, and everything that they possibly can in order to proactively prevent many current and future web application security threats.

3) I came up with a protection solution here:http://sla.ckers.org/forum/read.php?13,6918,7005

This solution only currently works in Firefox, and it can be implemented either as:

a) How you use your web browser

b) How browsers are implemented

This is probably the strongest protection methodology currently available for users. I use it myself.

I’m using it right now. Firefox is open in this window to a totally locked down install (I’m even using Public Fox to lock down my settings with a password). A few other Firefox instances are open, but they have totally different profiles and they are running as different processes. This Firefox had a deny any policy on its NoScript plugin when started. I had to add access for this site to post this, so I temporarily allowed scripts only to http://taossa.com. I’m going to close this window and end this instance / Firefox process when I am done, clearing all private data.

4) While my method does seem to prevent many current and future threats, especially threats that exploit trust relationships in the same-origin policy - I can see two other protections getting into browsers quickly and easily.

a) You already mentioned one:http://myappsecurity.blogspot.com/2007/01/xss-filter-to-protect-from-xss-attacks.html

b) RSnake is also working with the .NET-Fw Anti-XSS Microsoft guys to have their own XSS filters put into IE7:http://ha.ckers.org/blog/20070119/microsoft-engineers-are-paying-attention/

I believe that each has their own immediate problems:

A) they don’t solve any same-origin policy trust issues directly

B) they work only as a protection against XSS

C) same problems as WAF’s below

5) Should I even mention WAF’s? Do we really want to put mod-security in browsers, Linksys routers, and in front of every web server in the world? The problem with Web application firewalls is two-fold:

a) They would need to be updated to support new threats

b) There is always going to be a way to sneak past their filters

6) Input validation can fix every XSS vulnerability in every application.