Death of open crossdomain.xml’s? (Flickr, Youtube,…)
December 13th, 2006
Note: Just found about about the Flickr deal, it got moved to http://api.flickr.com/crossdomain.xml
I must have missed Flickr shutting down their crossdomain.xml, here is a post by Chris Shiflett. I found the issue when looking at some old Flex Flickr mashup I wrote a while back and realized it was coming back with a security error. Then I noticed the http://flickr.com/crossdomain.xml is gone.
Just recently youtube.com changed their crossdomain.xml also. What is happening???? How will true Flex mashups work? If all the sites restrict their crossdomain.xml then what are we left with. Note: It is still possible to use a proxy server (PHP, ASP etc…) to do the same thing, so why lock down the crossdomain.xml? The proxy server’s also cause you to transfer all that bandwidth through your server, basically a double take on the same data.
Another side I have seen is in big corporations like Salesforce. They have a whole platform for building applications that you can sell to people as add ons to the base Salesforce offering. You can find them at http://www.salesforce.com/developer/. But since their crossdomain.xml was locked down you can’t build SWF type apps (unless they residue on their servers), this is where Flex could be used to create a lot of special add on widgets (charting, etc…) on top of one of the largest CRM online services in the world. They have not opened up the their crossdomain.xml to the world yet. There is a little something going with *.breezecentral.com though, just check out http://salesforce.com/crossdomain.xml. This is because Adobe or some consultant with Adobe wrote some Adobe Connect (formerly Breeze) Saleforce integration applications I guess. Nice to see Adobe has a relationship Salesforce to get them to change the crossdomain.xml.
Where does this bring us to. Well I think there is a fine line that companies don’t understand about the power of the crossdomain.xml. If they have open API, but then restrict access, its a slap in the face for the Flash/Flex of developers. With the rise of RIA’s and Flex pushing many cool and complex multi-service mashups it will be a shame if we are all locked out because of mis-information or lack of proper education about the crossdomain.xml and security issues.
Another Note: So can somebody explain the difference of security and using the API to login to Flickr or using the main page? Here is the context:
Chris found that flickr had a crossdomain.xml file setup to allow flash applications to be built using the Flickr API. The problem is that you can write a flash application that would allow almost any action a logged in flickr user could perform.
Flickr has fixed the problem by moving the API endpoint, and crossdomain.xml to api.flickr.com, instead of running under something like flickr.com/api. Now a flash application can’t make calls to flickr.com from another domain.
Is this a issue of the Flickr open API nothing allowing all the functionality that could be spoofed on the website? Ok fine and dandy makes sense, but that doesn’t stop some malicious Flash (or PHP/ASP) Flickr mashup from taking your username and password and using it on the main website wrongly, correct?
Note: CSRF stands for Cross-site Request Forgery
Entry Filed under: Adobe Flex, Rich Internet Applications
19 Comments Add your own
1. felix | 2006-12-13 at 12.55 pm
flickr’s crossdomain file is now at: http://api.flickr.com/crossdomain.xml
So you still have access to all the flickr API through flash.
2. Renaun Erickson | 2006-12-13 at 1.00 pm
just caught that, so does the change really matter? Check out my “Another Note” section up above.
3. John Dowdell | 2006-12-13 at 2.05 pm
Hi Renaun, I’ve been trying to get solid info on this, but am hitting a wall now… we’re entering the end-of-year slowdown here in the US and many offices will be closed, and the natural contact inside Adobe for this, Flash Player Product Manager Emmy Huang, was recently married and is on honeymoon through this period. I’ve got few resources through the holidays.
I’ll post if I get info, but I don’t have particular contacts within those services myself.
(I’ve heard some express concern that these services used wildcard access, which enables spoofing of their cookie-based user sessions. If so, then a signup program should accommodate both goals. I don’t have a solid grasp of what their perception of the issue actually is, though.)
jd/adobe
4. James Ward | 2006-12-13 at 2.11 pm
Crossdomain files can be very dangerous if used on sites with cookie or basic authentication. This immediately opens those sites to CSRF attacks. I think a good Web 2.0 solution would be for someone to create an open proxy server which just forwarded requests from like api.flickr.myopenproxy.com to api.flickr.com. That way eveyone could use a proxy which doesn’t do token authentication for the final destination site. Any takers?
-James
5. Renaun Erickson | 2006-12-13 at 3.00 pm
So if I get this right, a Flash/AJAX app could access that domains scripts by using the cookie set in the browser? Regardless of if they asked for a username/password or not.
So the idea is that since api.flickr.com does not hold cookies for the the flickr.com main website, you can’t spoof login. And the mashup could still ask for a username/password for its only purposes though, correct?
Seems like we need some Adobe dev center write ups in this area, touching on Mashups, Open API’s, and proper usage of crossdomain.xml when used with other systems in place.
6. Evert | 2006-12-13 at 3.19 pm
That is exactly it renaun..
If somebody is logged in to flickr and they have an open crossdomain.. a swf hosted on a totally different site can invoke actions as if it was the user (since the cookie is shared).
It’s irresponsible to leave it open, and yes.. there hasn’t been much communication from adobe to make people aware..
There’s loads of sites out there that still have this open, and therefore you are, as a user, at risk..
The problem actually goes deeper than that.. if you are somehow able to upload something looking like a cross-domain.xml (even if its embedded in a GIF or deep in an html file) you can do the same thing..
I suspect we’ll see more of these type attacks pretty soon..
7. Evert | 2006-12-13 at 3.27 pm
Things would be way more secure if the flashplayer only accepted valid crossdomain.xml files, by the way..
8. James Ward | 2006-12-13 at 4.32 pm
Evert, what do you mean by Flash player only accepting valid crossdomain.xml files? I think the crossdomain policy file feature of Flash is really useful, but it can also be very abused by people who do not understand the implications. We (Adobe) need to do a better job educating people about potential crossdomain security problems. Much of this can be learned by reading the Flash security whitepaper, but we probably need a better, less verbose article. I will contact some people to get the ball rolling on that.
9. Renaun Erickson | 2006-12-13 at 4.35 pm
James,
Good to hear, i think some basic specific problem/solution examples in a short article would be good. At least in the space of mashups and open API’s that really is the key to alot of growth in the RIA space.
It would help Flash save face by being proactive about the security issues instead of being a news headline about how some big site had some security issue exploited by Flash apps.
10. Evert | 2006-12-13 at 4.45 pm
James,
Currently the flashplayer also accepts crossdomain policy files embedded in HTML or even GIF files.. read this:
http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
11. Chris Allen | 2006-12-13 at 4.49 pm
James, I would also like to see a more concise document on the Flash security model created. In addition, there doesn’t seem to be too much out there about the security model when using a projector. This is something that we have been struggling a bit with at my current job.
12. Crossdomain.xml revisted &hellip | 2006-12-14 at 3.50 am
[...] This is a great summary of the security concerns regarding crossdomain.xml files. There’s been a lot of talk recently about crossdomain.xml, following John Dowdell’s post regarding the change in policy at YouTube. [...]
13. John Dowdell | 2006-12-14 at 1.39 pm
I just heard through internal email that there’s already more documentation in the pipeline for these types of issues. Probably won’t get final reviews and live push until after the holidays, though.
It still would be good if Flickr and YouTube spoke for themselves on this issue, though.
jd
14. Renaun Erickson | 2006-12-14 at 1.42 pm
I agree, the documentation should not just be Adobe, but also developer documentation from each service. Granted they will not want to talk about security risks in great detail. But general security guidelines in regard to each services specific implementation would be great to see from the services themselves.
15. joeberkovitz.com » &hellip | 2006-12-14 at 2.35 pm
[...] Death of open crossdomain.xml’s? [...]
16. Eric cancil | 2007-02-26 at 11.45 am
Ok, maybe I’m not totally grasping this. It’s fine that we can access the API without any sandbox violations, but we can’t access the actual pictures without one, doesnt this defeat the purpose?
-Eric
17. Renaun Erickson | 2007-02-26 at 11.49 am
Not sure what you asking here… are you saying you can’t access the flickr pictures directly in Flash/Flex without a crossdomain.xml?
18. Abrupt YouTube security p&hellip | 2007-03-27 at 11.28 am
[...] It seems Flickr did it too… seems like Death of open crossdomain.xmls. Read the post by Renaun Erickson [...]
19. Mrs. Weasley | 2007-09-17 at 10.00 pm
Any news on Salesforce’s crossdomain.xml now that they have their Flex Toolkit? Seems like the toolkit should handle the communications between my app and salesforce.com, and I didn’t notice anything about using a proxy in the online code samples from Salesforce.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed