Jump to content

Insecure Flash Cross-Domain Policies Expose Users to Abuse on One in Ten Websites


Batu69

Recommended Posts

968 websites in the Alexa top 10,000 are vulnerable



Computer security specialist Julio Cesar Fort has studied how the top 10,000 websites (according to Alexa) deal with their Flash cross-domain policy, and found that almost 10% of the sites, have unsecure policies which expose users to abuse.



The Same-Origin Policy (SOP) is an important part of how Web browsers work, and was set in place to protect users from attackers that use scripts loaded on domain X to attack users accessing domain Y.



While browsers have implemented the SOP for years, there is a way for Flash applications to control who can load or access Flash resources using the crossdomain.xml file.



As Adobe explains: "A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction."



This file, as Mr. Fort explains, can be used by attackers to perform CSRF attacks via malicious Flash applets, technically overriding any anti-CSRF measures built into Web browsers.



31% of websites have an exposed crossdomain.xml file



Wanting to see which websites have an insecure policy, Mr. Fort scanned the top 10,000 sites on the Internet for the presence of a crossdomain.xml file. His research showed that 3,110 sites listed this file in their domain root, making it accessible for anyone interested in looking.



In this file, webmasters can declare which sites are allowed to access its resources via the "allow-access-from" XML tag. This file supports wildcard declarations in the form of "*.domain.com."



This is considered an insecure practice, mainly because attackers can sometimes gain access to only one sub-domain, or even set up their own sub-domain on infected services, and then use it to perform CSRF attacks via the crossdomain.xml file.



According to his research, Mr. Fort found that 968 websites, 9.68% of the top 10,000 Alexa sites, included wildcard declarations in their crossdomain.xml file.



And if you were wondering, yes, the weak Flash cross-domain policy has been used already to hack websites. Matthew Bryant has already done it to Rdio.



Fortunately, he's a white-hat and disclosed the vulnerability privately so it could be fixed.



Source


Link to comment
Share on other sites


  • Replies 2
  • Views 1k
  • Created
  • Last Reply

A tightly configured NoScript floats my boat — Adblock Plus does the job on a remedial basis (however, NoScript is equipped with preventive measures.) F3h9xqz.gif

Link to comment
Share on other sites


If you run your own website and host either Acrobat or Flash content, making your crossdomain.xml file read as follows is the tightest you can get:

Cross-domain-policy: Least permissive policy

<?xml version="1.0"?><!DOCTYPE cross-domain-policy SYSTEM"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"><cross-domain-policy>   <site-control permitted-cross-domain-policies="none"/></cross-domain-policy>

A chmod of 644 on this xml file has yielded no ill-effects since the days when Flash content was all the rage...

That's all folks!

:jester:

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...