As has been said over and over, allow-all cross-domain policy files should never be used on domains, where users log on. This leaves the site open for CSRF attacks from flash clients on different domains, that can load pages from the target domain utilizing the user’s automated log-in and thus the flash load’s the pages, like the user himself would. This not only allows the flash file to (without the user knowing it) load all his private information from the target site, but potentially also post data to the site, which could include updating the user’s password, email, profile or in worse circumstances add/remove content or even make purchases, if the target site has any feature like that.

This has been done against large sites like Facebook, MySpace, Adobe and Youtube – the latter was ironically documented via a video on Vimeo by Jeremiah Grossman.

In Vimeo’s case, you can “only” upload videos, but an attacker could actually perform any action on the user’s behalf, that the user himself could – including changing the user’s bio, add/remove videos, comment on/like other videos etc. I made a small, seemingly innocent page, that included a hidden flash element, which first loaded the user’s info from vimeo.com/settings/personal and then re-posted this info back to the same page adding an extra line to the bio – namely “You have been bwned”, as it can seen on my vimeo profile.

Someone at vimeo has clearly seen this demo, (Julia Quinn has indeed) and now the cross-domain policy only allows *.vimeo.com (the new file is served with a Last-Modified timestamp of Thu, 11 Feb 2010 23:32:05 GMT, so the change is only an hour old). The strange thing is, that if you go back via the Wayback Machine from archive.org, you can see, that they had much better security back in 2007 and 2008 (html render fails, but view source), so I have no idea how such a relaxed policy suddenly appeared on their site. Google’s cache still show the allow-all policy as it dates back to January 20th (again, view source to see contents).

I found this while playing around attempting to load videos from Vimeo directly in a custom FLV-player on a different host than vimeo.com and found that this was actually possible, as all videos from their site are hosted from av.vimeo.com and this has an allow-all cross-domain policy. And this makes sense, as this domain is only used for serving videos and nothing else – no cookies or authentication info shared to this domain.

I haven’t heard from Vimeo yet – neither stating that they are looking at the issue nor that it has been fixed. I only post this after now seeing, that it has been fixed.

No related posts.