I came across this article - link to article - on another site and have been discussing it with some friends. Here is an excerpt:
"Hackers can exploit a flaw in Adobe's Flash to compromise nearly every Web site that allows users to upload content, including Google's Gmail, then launch silent attacks on visitors to those sites, security researchers said today.
Adobe did not dispute the researchers' claims, but said that Web designers and administrators have a responsibility to craft their applications and sites to prevent such attacks.
"The magnitude of this is huge," said Mike Murray, the chief information security officer at Orlando, Fla.-based Foreground Security. "Any site that allows user-uploadable content is vulnerable, and most are not configured to prevent this."
The problem lies in the Flash ActionScript same-origin policy, which is designed to limit a Flash object's access to other content only from the domain it originated from, added Mike Bailey, a senior security researcher at Foreground. Unfortunately, said Bailey, if an attacker can deposit a malicious Flash object on a Web site -- through its user-generated content capabilities, which typically allow people to upload files to the site or service -- they can execute malicious scripts in the context of that domain."
Now as I read it, the problem is for sites that allow user uploads, which will be ours. My hosts suggestion was abstain from using Flash, which is the obvious way to safe guard your site BUT is there another way? Maybe use a separate domain to store uploads and call those needed files to the main domain when needed as the problem seems to be domain specific. I don't know how to do this on my end. I figure this is something that is written into the scripts code. Which means Markus has another headache to contend with.
... thoughts?
![[[CLICK_OPEN]]](templates/wlite/images/open.png "q")
February
Security options ⋅ Markus November 17, 2009, 01:06 AM
As I noted in the parallel thread in the forums, this is obviously an issue that we will need to address — thanks for bringing it up here. Wiccle wrapup and release are just behind the corner, and since it's unlikely I will have the time to dedicate to going into nuances with the way Flash security is handled, I'll do with a solution that leaves the ends open for the user to configure as more information and possible exploit attempts surface.
There will be an option for configuring a separate domain / subdomain for user uploads to keep flash and other possibly hazardous media isolated from the actual site. Upload file type limitation is already in place, I still have a bit of work to do with upload MIME type recognition for an added layer of verification.
Clam AntiVirus upload scanning integration is also on the desk here, just haven't had enough time to look at the standard responses of different Clam server setups yet. While it probably doesn't catch the latest flash exploit attempts (I don't think any virus radar does yet), it'll also give you a bit more certainty over what goes into your filesystem.
To conclude, as I requested earlier in the forums, if anyone comes across or can locate good articles that review this issue in some technical detail, please post them here for us to go over.
some links and info... ⋅ Footman November 17, 2009, 01:44 PM
I've looked around a bit and found some info that may or may not be helpful. Unfortunately Adobe is still saying the security hole is "unpatchable" which puts the onus on the site owner AND the end user to handle it for now. Adobe, as of yet, hasn't even released a security bulletin on their site. Their latest release is dated October 12, 2009 and this issue isn't addressed.
A quote from an article I found. Full article
This might be a 'decent' fix for the surfer but what do we do as site owners? Apparently the best way, so far, for us to handle this is to host user uploaded content on another domain, such as described in the same article above.
Something coming down the road a bit might also mitigate this and other breaches we're subject to due to user uploads and that is the advent of HTML5. An excerpt from Wikipedia...
Looks like the best course of action at this juncture is to either NOT use flash at all or host user generated content on a separate domain. All of which is beyond my understanding. So I'm very happy that we have big brain guys like Markus around to mull it over.
Keith Killilea November 23, 2009, 10:58 PM
Nice blog Footman! Keep them coming
Follow-up on the Flash security issue ⋅ Markus January 23, 2010, 11:57 PM
To follow up on this — since iWiccle currently doesn't allow Flash upload to begin with (and so far I haven't heard anyone losing their sleep over it), implementing this measure was a bit of a moot point as the situation would not arise to begin with.
The requirement for a separate upload domain is something we will be including in the future though — whenever I get around to developing the system to work on clustered servers, it's a part of the deal by definition. If someone has a pressing need for getting flash uploaded safely in the meantime, please post in the forums / contact me and let's see what we can do about the situation.
I'm personally not a big fan of Flash uploads in 98% of the cases... Flash is a tool that lets you tween things around so easily that you have no idea how big a hit all that processing makes on just a little bit slower machines — I've had CPU usage at 100% and the PC crawling with a couple of badly produced flash ad banners warping their way to high heavens on more times than I care to count on my old (reasonably modern) laptop.
Imagine every Tom, Dick and Harry uploading their latest concoctions and having a forum thread page full of "cool" user avatars flip-kicking around. Combine that with the general "fun" things you can embed into flash totally independent of the security issue featured here, and you get a pretty good idea of why I am not a big fan of Flash for most purposes people seem to be (mis)using it.
---
There is of course a general concern for embedded flash, regardless of its origin. Currently the TinyMCE editor used in iWiccle has been configured to allow "embed" and "object" tags (that let you embed flash objects from remote sources). If someone wishes to remove the flash-embedding capability from the editor, you can open up tiny_mce_init_full.js under /plugins/tinymce/ and remove the line "extended_valid_elements" from the configuration, along with the "media" entry from the theme_advanced_buttons2 toolbar configuration to remove the front-end for it.
To complete the filtering at server-end, browse to Admin CP > System > Security and edit out "" from allowed tags for posts.
Markus January 24, 2010, 12:01 AM
So I got filtered there. =) The last sentence says, remove "embed, object, param" tags from there.
I am not fan of Flash at all. . . ⋅ Naomi October 24, 2010, 11:09 PM
But the what's the alternative to flash content?