breadcrumb arrow home | blog

You can't always blame someone else

Posted: 17/11/09

An image of You can't always blame someone else

A new security vulnerability was posted last week on a number of poorly researched blog posts, and whilst I tend not to comment on these kind of issues, I felt I knew enough about this one to see that Flash was been unnecessarily beaten for something that it hasn't done wrong.

Put simply, the issue occurs when a user-generated SWF file is uploaded to a website, then served from the same domain as the website itself (from say http://site.com/uploads ) and is then embedded in the page with the allowScriptAccess parameter omitted or set to sameDomain. This means that the SWF that the user uploaded could execute malicious script injections, with the origin appearing to be the main website, not the user-generated SWF - Cross-site Scripting.

Reasons why this isn't Flash's fault:

1) User uploads shouldn't been living on your main site domain, and if you can help it, they shouldn't even be on the same server as your web app! Many web apps don't interrogate files that are uploaded, to verify that they are what their file extensions say they are. There have been many hacking exploits through malicious scripts being uploaded as GIFs and JPEGs, which are then being executed once they're on the server. If you keep all of this content sandboxed away from your web apps, preferably running on a different sub-domain, there's no issue. Remember, the default allowScriptAccess parameter is “sameDomain", so if your users' SWFs are served from http://uploads.site.com, script injections into pages being served from your parent domain, or another sub-domain, won't be permitted.

You should never implicitly trust user-generated content. All content from a user should be treated as suspect, and handled as potentially incendiary until such a time as it can be verified as safe. You wouldn't directly add user input to a row in your database without first checking it didn't contain a ';DROP TABLES statement in it, and same should apply to files that users upload.

2) Whilst the default for allowScriptAccess is “sameDomain" there are two other values that can be assigned to the this embed parameter - “always" and “never". Now, from my perspective, when I build a site and I'm allowing users to upload and embed their content in my page, the first thing I'm thinking about is how I “keep them in their box". I don't want them scripting my DOM, I don't want them invoking pop-ups, and I certainly don't want them to inject malicious code into my page and lead my visitors to think I did it! So when I know they're embedding a SWF, I set the allowScriptAccess parameter to “never", this means the SWF will never be allowed access to the External Interface. I do this in addition to the steps in (1). Adobe have recently announced the deprecation of allowScriptAccess="never" to enforce the practice of never serving untrusted SWFs from the same domain as your web site. Because of this, step (1) is now the single most important thing a developer can do to eliminate script injections from user-generated SWFs.

Adobe are powerless to prevent this problem without completely severing Flash's ability to communicate with the External Interface, and breaking a key feature. The only suggestion could be to set the default for allowScriptAccess to “never" to cater for those who don't know when and how they should be managing this setting.

Many other technologies can be compromised using similar techniques; for example, server code such as PHP, ASP, and Java can be uploaded as an image (i.e. changing the file extension to .jpg) and then executed by simply referencing the image URL. Is this the fault of the developers of these technologies? No. It's the fault of the developer who didn't expect that a user would attempt to do this and left their application wide-open to exploitation. On the client, JavaScript can be injected into pages through unsanitized form input - something a group of researchers stated could be affecting 68% of sites, and despite so much publicity about it. JavaScript can also be injected with images. Simply change the file extension of a malicious JS file to .jpg, upload to a web site that doesn't interrogate the file contents, then post a link to the image on the site. Some unsafe browsers (IE6 for example) will execute the code. Allow users to upload MP3 files, and the same again is true; without sanitizing the file on the server, a hacker could use your site to distribute viruses to anyone who then downloads the supposed MP3 file from your site.

What I'm trying to say here is that if you give someone a set of tools, and they're not appropriately versed on how to use them, they could hurt themselves (and others)… A little knowledge can be a dangerous thing; as developers we have a responsibility to protect end-users from being exploited by hackers by ensuring we understand the full capabilities of the web applications we're building. Arguing that we shouldn't have invented electricity because someone killed themselves with a botched wiring job isn't the answer here.

Keywords for this post: flash, flash player, xss, script injection, javascript, external interface, security, vulnerability