3 Replies Latest reply on Mar 10, 2008 5:10 PM by paul928

    Comments on the new flash player 9 security

    paul928
      First of all, I want to start this with the fact that I am a serious actionscript developer for many years and have supported flash as being the platform of choice for rich internet applications. I want to comment that the security changes that are being required in the new flash player do not add a single thing to the overall security of the system. The primary reason for the new changes are to prevent dns rebinding attacks. The whole idea of dns rebinding attacks are stupid. People should have authentication on xmlsockets. Problem gone. If they don't have the intelligence to do that, no amount of the other crap is going to secure the application.

      If Adobe truly wants to add security to a system, they should add encryption over xmlsockets. Right now, everything sent or received over xmlsockets are in clear text and there is no workaround for it. In order to add a modicum of security, I have to open an ssl page to get an encryption key and use that for my xmlsocket, so that I can encrypt the password for logons. I would like to encrypt the entire connection, but the actionscript virtual machine is too slow to even handle rc4. Adobe should add access to c++ encryption/compression functions through the actionscript 2 virtual machine so that developers can actually encrypt the data being sent and received from my server without the as2 virtual machine crawling to a halt. While you're at it, add the ability to send binary data through xml messages so I don't have to convert my encrypted messages into bloated base64. THAT would actually add real security and it could be opted into without breaking applications.

      Compare that to the current scenario. Adobe thinks it's ok to require everyone to run a policy file server on port 843. Ok, there are so many problems with this that it's not funny. First of all, this breaks existing code. BAD, BAD, BAD. If you're going to do something to break existing code, it better be a really good reason. Setting up a "master policy server" in not one of them. If you absolutely had to have a place to put the master policy server, why not use the root of the webserver??? What advantage do you get by forcing everyone to develop and setup a new server on port 843? I'll tell you. None. Second, running a server on port 843 requires root privileges on a unix box. So, now you're forcing administrators to run a process as ROOT. nice. Port 843 is not going to be opened by any serious firewall and it won't be for a long, long time. Second, why the hell wouldn't they release an xmlsocket server that can actually run on port 843? We're supposed to figure that out on our own? Stupid. Oh, and then there's the documentation which is completely incoherent. There have been SO many changes to this crap over the last two years that the documentation is completely contradictory. So, as a developer, you're left to use only the latest documentation, but it's not clear on a lot of stuff. It took me two days to figure out that there is a difference between url and socket policy files. I'm STILL trying to figure out why there are TWO of them. So, on top of breaking your application, providing no warning to the community, providing no policy file server to run, providing confusing documentation, the flash player has bugs with the implementation of socket handling so that even after you do everything adobe wants, it STILL DOESN'T WORK!!! Apparently, the flash player intermittently doesn't get policy file requests on port 843. What the HELL! Sorry for this rant, but it's 6am and I'm working on finding a workaround for this for my customers and it's foobar'ed.

      Adobe has been completely non-responsive to the community on this issue.
      http://bugs.adobe.com/jira/browse/SDK-14853
      http://bugs.adobe.com/jira/browse/SDK-14610

      Two bug reports have been filed and Trevor Baker just closes them, first because he claims they are duplicate, which they are not, and then redirects the bug reported to a flash bug database which gets no attention. They don't even have a bug database browser.

      It's a shame. Adobe does so many things right and then they ask a complete neophyte to do the security on their platform, breaking applications, ignoring real security issues, and ignoring pleas for help from the community. Fire the security guy and the QA guy, together they're complete idiots out of touch with what real security and usability issues. Seriously.
        • 1. Re: Comments on the new flash player 9 security
          paul928 Level 1
          Oh, and I just want to comment one more thing.

          Yahoo! - http://api.search.yahoo.com/crossdomain.xml
          YouTube.com - http://www.youtube.com/crossdomain.xml
          Flickr.com - http://api.flickr.com/crossdomain.xml
          Amazon.com - http://www.amazon.com/crossdomain.xml

          Apparently all the major websites out there write generic open access crossdomain files, validating the fact that this thing is less than useless. These sites have a lot of resources and if they thought it was any value at all to use this for security, they would.
          • 2. Re: Comments on the new flash player 9 security
            Level 7
            >>Apparently all the major websites out there write generic open access
            >>crossdomain files, validating the fact that this thing is less than
            >>useless.

            I don't think you're understanding exactly what crossdomain.xml is for...
            These major sites have it wildcarded so that people can develop Flash
            applications that use those sites API's/services - and run them from any
            domain they like. So, I can develop a Flash book finder, that grabs data
            from Amazon, and stick it on my blog.
            Other sites that don't want to let just anyone access their data, specify
            only the domains they want to allow access from. I use a crossdomain.xml
            file on a current project and it works as it should - only allowing access
            from the three domains I have listed.


            --
            Dave -
            Head Developer
            http://www.blurredistinction.com
            Adobe Community Expert
            http://www.adobe.com/communities/experts/


            • 3. Comments on the new flash player 9 security
              paul928 Level 1
              > I don't think you're understanding exactly what crossdomain.xml is for...
              > These major sites have it wildcarded so that people can develop Flash
              > applications that use those sites API's/services - and run them from any
              > domain they like.
              I understand exactly what the crossdomain.xml is used for. The point is that this is how everyone uses crossdomain.xml.

              > Other sites that don't want to let just anyone access their data, specify
              > only the domains they want to allow access from. I use a crossdomain.xml
              > file on a current project and it works as it should - only allowing access
              > from the three domains I have listed.

              And you think this provides any security at all? It's you that is confused. Crossdomain.xml provides the most basic obfuscation for security. Only Flash Player cares about crossdomain.xml. That means that anyone with any other program can access your data through any number of means. i.e. web browser, telnet, perl script, c programs, etc.

              Adobe is seriously misleading people by implying this adds anything at all to security.