|
In this article, I'll describe one of the important differences between the JavaScript security model and the one used in Flash apps. Flash's approach to cross-domain requestsFlash will let your .swf file make requests for other URLs on the same domain the .swf was loaded from, and your .swf will be able to examine what gets loaded. But it won't make requests to other domains unless the other site gives permission, by hosting a cross-domain policy file (usually called crossdomain.xml) that lists the sites that are allowed to make requests. Let's say you have a nifty Flash-based email client that you serve up at http://www.example.com/mail.swf. It seamlessly integrates with your address book application by requesting addresses in XML format from http://www.addressbook.com/. To get that to work, you created a file http://www.addressbook.com/crossdomain.xml that looks something like this: <?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" secure="true" />
</cross-domain-policy> That file tells the user's Flash player "I don't care where you loaded the currently running .swf; feel free to allow it to connect to me." So when http://www.example.com/mail.swf loads and makes a request for http://www.addressbook.com/getmybook, the Flash player notices that the request is from a different domain than the one that mail.swf loaded from. So before it makes the request, it automatically checks to see if there's a cross domain policy file at http://www.addressbook.com/crossdomain.xml. There is, and it says that apps served from any domain (domain="*") are allowed to make requests, so the Flash player allows mail.swf to load the getmybook URL. Of course, the addressbook server shouldn't hand out your addressbook to just anyone; you'll have to have logged into addressbook.com first so that your browser has the proper cookies to present when it makes the request. Note that the cookies are the same cookies used by the web page serving up the .swf app, so having an insecure .swf affects your AJAX app too. But here's the problem: I create a .swf program on evil.com and get you to load it while you're logged into addressbook.com. Perhaps I send you a link to it via email, or you happen to run across it while your inbox is open in another tab. My evil .swf tells your browser to load your address book, which it's happy to do because it sees that http://www.addressbook.com/crossdomain.xml allows it, and then relays the contents back to me. It can do that because in Flash, .swf applications can see the contents of any URLs they load. So it's important to write your crossdomain.xml files carefully, since any Flash application on the domains you grant access to will be able to see the data you serve up from your domain. Those Flash apps won't be able to see the innocent user's credentials, but the credentials will still be sent when the user's Flash player loads up that data. What crossdomain.xml WON'T protect you fromThe vulnerabilities described in this page result from a user's browser making requests on behalf of the user and giving that data to untrustworthy apps. That is, we want to prevent users who happen to load some evil.swf file from having their browsers agree to make requests for the user's data stored on google.com and hand that data to an adversary, or having that app perform actions on behalf of the user (like deleting all their mail). But crossdomain.xml files can never ensure that all the requests that come to your server were generated by your .swf app. Malicious users can (and will!) make requests to your service all day long, trying out all sorts of funny values for parameters that your .swf app would never generate. The crossdomain.xml policy file can only ensure that honest users don't have their accounts hijacked by an attacker who can get the user's browser to do something your crossdomain.xml allowed but didn't expect. Wildcards can open new attack vectors at any timeImagine that your project's data lives at data.example.com, but the app requesting the data lives at www.example.com/app.swf. You create a policy file, http://data.example.com/crossdomain.xml, that allows accesss from domain="*.example.com". This is convenient, since users can load the application from http://www.example.com/app.swf, http://example.com/bar.swf (without the www. prefix), or possibly even http://otherproject.example.com/app.swf (depending on your server's settings). Now imagine that another team in your company creates a new project hosted at uploads.example.com. They launch a year after your application with a security hole which allows anyone to upload .swf apps and have them served via the domain uploads.example.com. Your project's data is now vulnerable, since your cross-domain policy file said that you're happy to talk to any .swf app loaded from *.example.com. Solution: don't make your allow-access-from URLs more permissive than necessary. Think before using wildcards; if possible, list specific URLs and avoid wildcards altogether. Secure requests from non-secure pagesSetting secure="False" in a crossdomain.xml file served over https allows .swf files loaded from http: URLs to access https: URLs on the server. This should be used with extreme caution. If an attacker can trick a client into loading something evil off of example.com, setting secure="False" makes the data served over SSL (on https://example.com/) just as vulnerable. Taken together with the wildcard problem noted above, Setting secure="False" on yourdomain.example.com could end up compromising far more than just your own project's security. Further reading
|
