4 Replies Latest reply on May 28, 2007 2:21 AM by anil_parashar

    crossdomain.xml security issues

    dazweeja Level 1
      What I'd like to do is create a simple Flex application that can be distributed to any (ie. untrusted) source that reads data from my web server using AMFPHP. I understand that this requires a crossdomain.xml file.

      I'm trying to get my head around the security implications of open (ie. allow all) crossdomain.xml files. Basically I understand that issues arise when there is an open crossdomain.xml file on a domain that uses cookie/session-based authentication as the SWF can read/forge the cookie info that is sent in the HTTP header. This allows cross-site forgeries and other unintended consequences. My main concern is with server security though. What are the implications as far as compromising the security of the server aside from forgeries and spoofing? The Adobe article linked below suggests that crossdomain.xml files may allow access to other private severs on a network which is obviously quite serious.

      If I understand correctly, a lot of the risk can be mitigated by hosting the crossdomain.xml file on a separate sub-domain from the domain with the user authentication mechanism. Is this as straightforward as setting up an Apache virtual host for a sub-domain which hosts a simple PHP script/gateway that forwards/returns requests to the domain which contains the data source?

      How have others got around this problem? Can you provide me with a brief explanation of your solution.


      If you don't understand what I mean by the security implications, these refs might help:

      http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.h tml
        • 1. Re: crossdomain.xml security issues
          My understanding of this is that the crossdomain.xml file simply identifies which domains incoming requests are allowed from.

          This doesn't give anyone any more control over your server than they currently have, it just stops flash player from accessing your server when it isn't in the list of authorised domains.

          robots.txt is more dangerous to a website owner due to the fact that it can provide information about the underlying site.

          crossdomain.xml doesn't contain any information about the site or server, just which domains are allowed access to the webserver.

          The security implications are mostly due to your PHP coding in the back-end.. If you do not check to make sure that this flash user is allowed before giving data to it then you can cause a security hole.. But thats your problem, not flashs'..

          Basically nothing new can be done with flash with regard to security. It all can be just as easily done using off-the-shelf tools like "Firebug" for the firefox browser, or "nettools" which is a java based HTTP test *fraud* tool..
          • 2. Re: crossdomain.xml security issues
            onlysport Level 1
            After reading my post - crossdomain.xml *may* provide information about the other servers in your network, if you explictly define them..

            <allow-accesss-from domain="*.mysite.com"/>
            <allow-accesss-from domain="my-private-server.mysite.com"/>
            <allow-accesss-from domain="financials.mysite.com"/>
            • 3. Re: crossdomain.xml security issues
              dazweeja Level 1
              The way I understand the main security risk is this:

              Bob visits Flickr (or Yahoo or Youtube), logs in and uploads some photos. He then visits evilsite.com, which silently loads a malicious SWF. Because of Flickr's open cross-domain policy and the advanced HTTP header-reading/modifying ability of Flash, the SWF from evilsite.com is able to read Bob's session cookie from Flickr and then inject it back into a header to Flickr, giving it the capability to do anything it likes with Bob's Flickr account, like delete all of Bob's photos (unless Bob remembered to log out before he left Flickr). It's sort of like the MySpace worm but potentially more dangerous because it's cross-domain as well. Some might say "Well, this can be done with other specialised programs". That is true but it is extremely unlikely that any of these programs will be installed as plug-ins in innocent Bob's browser. You can't do this cross-domain stuff with Ajax or Javascript, only Flash. This is explained a bit better in the top 2 refs in my original post but it is a real security concern for any server that has an open crossdomain.xml file and uses some type of cookie/session-based authentication.

              I'm looking for a way around this and I think the sub-domain thing is the way to go. I'd just like to hear from someone who's actually done it.

              • 4. Re: crossdomain.xml security issues
                You can use FDS where proxy-cofig.xml will handle this thing .
                you don't need to worry about crossdomain.xml.