Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi everyone, Bryan here. Peleus Uhley, Senior Security Researcher at Adobe, has written a guest post for the BlueHat blog on potential security issues with cross-domain access permissions for web sites. I’d like to encourage you to read Peleus’ post and also to expand on it a little to talk about the SDL requirements around cross-domain access.
Normally, the Same Origin Policy prevents web pages from interacting with resources hosted on domains other than the one they were loaded from. This is done for security reasons; without the SOP it would be trivial for malicious sites to steal or alter data on other sites. However, there are so many great legitimate uses for cross-domain access (like creating client-side mashups) that several technologies have been developed to allow it under limited, opt-in circumstances. These technologies include:
· Flash’s crossdomain.xml policy file, also used by Silverlight
· Silverlight’s clientaccesspolicy.xml policy file
· IE8 XDomainRequest object
· XMLHttpRequest Level 2 Access-Control headers
Now, there’s nothing inherently wrong with any of these (although I have argued in the past that cross-domain XMLHttpRequest would destroy the internet). The problem with using these is that it’s easy to inadvertently expose data to sites you don’t intend to expose data to. Using wildcard domains when determining which domains have access permissions exacerbates this problem. The canonical example of this (no pun intended) is the crossdomain.xml setting
This setting basically opens the web site up to cross-domain access from the entire internet.
To help prevent sites from unintentionally exposing data to malicious external domains, the SDL requires any site with authenticated access to enumerate the specific domains it is allowing access to – no wildcards allowed. Otherwise, the site is free to make its cross-domain access as permissive as desired.
The original draft of the SDL cross-domain requirement was slightly different. Initially, the requirement included restrictions on the use of wildcards based on the depth of the wildcard (i.e. two-dots vs. one-dot vs. no-dots) and whether or not the site provided a “private API”. If a site contained only completely public resources, then it was allowed to use wildcards at the two-dots level or greater; for example, *.live.com would be allowed (two dots) but *.com would not (one dot). If a site had any resources only accessible by authenticated users, then no wildcards were allowed; all domains with cross-domain privileges had to be explicitly enumerated in the appropriate policy file or header.
However, we later realized that this requirement draft was both overly complicated and overly restrictive. If a site is completely public – no authenticated access, no private or sensitive data – then there’s really no reason to restrict its access at all. The reason for this is that cross-domain attacks are luring attacks. To succeed, the attacker needs to lure a victim into performing some action on the attacker’s behalf. For example, a cross-domain attack against a stock trading web site might cause the victim to send the attacker the complete details of his stock portfolio, or might cause the victim to make unintended trades. But in a completely public site, there’s no personal data to steal and no possible authenticated actions to forge. There’s no reason for an attacker to perform a luring attack – they already have the same access to the same data that everyone else has.
When we realized that our requirement was too restrictive, we changed it to its current form. However, let’s re-examine the requirement in light of Peleus’ research on cross-domain access chaining. (To give an extremely brief summary for those who haven’t read it yet: cross-domain permissions are transitive. If site A grants privileges to site B, and site B grants privileges to site C, then site A is implicitly and perhaps unknowingly granting privileges to site C.) For the completely public site the potential of privilege chaining is a non-issue in terms of SDL requirements; we’ve already said it’s acceptable to grant global access if desired. However, the situation is more complicated for the site with authenticated actions.
It is true that even with wildcard domains being prohibited, there is still the possibility that one of an authenticated site’s allowed domains could chain access to a potentially malicious third site. Unfortunately, short of banning cross-domain access entirely, there is no way to completely prevent this possibility. In most situations it would be impossible to map out a list of 3rd and 4th and nth order chained domains at development time, and furthermore it would be pointless since the list could change at any time even after the app has been deployed.
In light of this research, we will be evaluating ways in which we can adapt the cross-domain requirement to continue to prevent unintended access from third-party domains. However, the requirement as it stands now remains useful and relevant. It raises the bar for attackers while imposing minimal design constraints and minimal time investments on the part of the development team.