[UPHPU] Flash Security

[Webot Graphics]

This is from an sitepoint newsletter just released. Some people at  
the last meeting expressed concerns for the flash security.



Cross-Domain AJAX with Flash Leads to Gaping Security Hole

What do Flickr, YouTube, Amazon, Adobe and Oprah have in common?  
Their sites were all revealed to be vulnerable to Cross-Site Request  
Forgeries (CSRF) recently. I wrote about CSRF attacks in Tech Times  
#144, but these most recent vulnerabilities are a result of a newly  
discovered mistake that is being made by these sites.

At Web Directions South a couple of weeks ago, Cameron Adams and I  
presented on the subject of JavaScript APIs and Mashups (slides and  
audio coming soon). The last thing we covered in the talk was cross- 
domain AJAX; specifically, I looked at a number of ways around the  
Same-Domain Policy that exists in current browsers, and which  
prevents you from using JavaScript code to directly retrieve  
information from another web site.

One of these work-arounds is to use Flash to enable communication  
with another domain. While JavaScript isn't allowed to communicate  
with another site, a Flash movie is—as long as that other site has  
published a crossdomain.xml file listing your site.

The security hole revealed late last month comes in when a site like  
Flickr wants to open its API up to everyone, and publishes a  
crossdomain.xml file that says anyone can use Flash to access the  
site. Macromedia published a Flash Player TechNote over four years  
ago that includes a few words about this:

"This practice is suitable for public servers, but should not be used  
for sites located behind a firewall because it could permit access to  
protected areas. It should not be used for sites that require  
authentication in the form of passwords or cookies."

While this is good advice, it doesn't go far enough to protect eager  
developers from making this serious mistake. By opening up access to  
your site with a "carte blanche" crossdomain.xml file like this, you  
are enabling JavaScript code on another site to pose as a logged-in  
user and access protected content and submit sensitive forms on their  
behalf.

The correct approach, which Flickr quickly adopted after having been  
informed about the vulnerability, is to host your public API on its  
own domain (e.g. http://api.flickr.com/) and put your wide open  
crossdomain.xml file on that domain only. Your main site, then, will  
benefit from the protection of the Same-Domain Policy and will not be  
accessible to Flash without first displaying a security warning to  
the user.

So, what lesson should ordinary developers take away from this? Well,  
I think we must accept that web security is a moving target. You  
can't just read a book and expect to know everything you need to keep  
your site secure today and in future. After all, if the hot shots at  
Flickr and Amazon can't get this stuff right, what hope is there for  
the rest of us?

Books like Chris Shiflett's Essential PHP Security will provide a  
solid foundation for you to work from, but you need to monitor  
ongoing developments in the web security domain. Reading this  
newsletter is a good start, but you should also find a trusted source  
specific to your platform of choice. For PHP, for example, Chris  
Shiflett's own blog is a great resource.




Justin Giboney
graphics at westernbotanicals.com