Microsoft and Adobe frequently work together on security. At this year’s BlueHat, we will come together to share our security research in the area of Rich Internet Applications (RIAs). While we independently place considerable thought and effort into our respective security models, attackers often look for methods in which to combine technologies for an attack. In addition, developers might combine two technologies without knowing the risks associated with mixing content. By sharing research and consolidating information, we can ensure that developers have the essential knowledge necessary to provide a secure experience for end-users regardless of the technologies that are combined to create that experience.
A single Web page may be a composite of the efforts of many different development teams, each utilizing different technologies. If you are responsible for the overall security of a site, then you need to have a clear picture of how content will interact in order to understand the risks. Without a clear mapping of permissions granted to each piece of content, an attacker might be able to find subtle paths through your defenses.
For example, I have been looking at many of the newly developed cross-domain permissions and hypothesizing how developers might make mistakes in deployment. My co-presenter, Jesse Collins, has already published on how cross-site scripting attacks due to coding flaws can lead to attacks on cross-domain XHR2/XDR implementations. On the other hand, I have been researching how architectural designs might lead to unintentional cross-site permissions. For instance, let’s say that woodgrovebank.com provides cross-domain XMLHttpRequest Level 2 (XHR2) permissions for their site to adatum.com. The adatum.com site also serves interactive third-party SWF advertisements that are provided with JavaScript access via the allowScriptAccess parameter. If the third-party SWF advertisement has access to the JavaScript on adatum.com and adatum.com’s JavaScript has cross-domain access to woodgrovebank.com, then the third-party advertisement has access to woodgrovebank.com. This may not have been what woodgrovebank.com had in mind when they provided cross-domain access to adatum.com.
As part of our research, we are supplementing our concepts with real world examples. For instance, the hypothetical example above is an abstracted variant of the recent renren.com worm. The writers of the Renren worm started with sharing a link to a malicious SWF file hosted on a third-party domain. Unfortunately, the renren.com HTML was providing that remote SWF with an allowScriptAccess permission of “always”. The “always” permissions allowed the remote SWF to have script access into the renren.com HTML. The SWF itself would do nothing more than play a Pink Floyd video (Rick Astley would be too obvious) and use its scripting permission to inject a SCRIPT tag into the hosting HTML. The SCRIPT tag would then load the malicious JavaScript that was responsible for driving the complex attack. The worm propagated by sending messages to the victim’s friends. To accomplish that task, the malicious JavaScript needed to collect information from different sub-domains of renren.com. Fortunately for the attackers, renren.com already utilizes cross-domain AJAX calls to those sub-domains as part of their architecture. Therefore, the attackers were able to initiate the attack by taking advantage of the excess permissions granted to the SWF content. They then leveraged the existing cross-domain AJAX infrastructure to collect all the information necessary to identify the victim’s friends and propagate the attack.
Combining research makes it easier to communicate common risks with deploying RIA technologies. The attacks in the above examples could also occur if the content were based on Silverlight and granted the EnableHTMLAccess permission. As the webmaster responsible for the overall site, you may not be an expert on each RIA technology. However, if you understand the common risks shared across RIA technologies, then you will know to ask whether the SWF or Silverlight content has access to your HTML’s DOM during your security review. Understanding the common risks will allow you to draft security requirements that can be flexible enough to address different RIA technologies.
During the presentation we will be providing guidance on how to secure your site against these and other RIA attacks. It is our goal to communicate some of the important commonalities and differences between RIA platforms to enable developers to understand the breadth of RIA’s capabilities Architectures that mix content from diverse sources will need to build holistic views of their content. Data flow diagrams detailing where cross-domain communication occurs can help identify where unintended paths into sensitive areas may exist. By understanding the capabilities of RIA technologies and by tracking the flow of those permissions, developers will be able to accurately manage their risks and provide users with a rich Web experience.
Peleus Uhley
Senior Security Researcher
Adobe Systems, Inc.
[Editor’s note: Check out Bryan Sullivan’s post on the SDL blog titled “Cross-Domain Security” discussing the existing SDL requirements around cross-domain access security and the implications of Peleus’ research on these requirements - coming soon.]