Please understand, I am a huge fan of Flash. I use it every day in my professional and personal work on the Internet. I believe, when used intelligently, Flash is an incredibly powerful tool for both entertainment and electronic commerce. But I am bothered when people try to use Flash in ways that end up making Flash look faulty. Bad Flash implementations make it harder for developers like me to sell customers and clients on good Flash implementations.

While there are problems inherent to VeriSign's approach that call into question their understanding of "The Value of Trust," there are ways they could have made this particular implementation less trivially spoofable. The flaws I demonstrate on this page are flaws in the concept and the execution rather than anything inherently flawed in Flash. Overall this kind of graphical "trustmark" is extremely easy to forge just by recreating the artwork. But in this case, you don't even have to do that. The seal can still be called directly off the VeriSign servers, yet it is easily modified, without recreating artwork, and without doing anything untoward with VeriSign's servers!

Please take a moment and view the page source, in which you'll see that the code for inserting these two Flash files is completely generic. There is no javascript in the HTML either. The seal is being called directly from VeriSign. You'll also see that I am not passing it any variables through the object and embed tags, yet I am still getting my custom value into it, and that value is not one originating at Verisign's server.

How the Real Seal Works:
In a normal usage, to deploy the VeriSign seal, you would include javascript on your page that passes your domain name to the Flash file sitting on VeriSign's servers. That script then writes the information into the Flash file, as well as several functions in javascript. (Unwisely, these functions have fairly generic names -- such as "splash" -- so it is just a matter of time before some sites see variable name collision with content already on the customer's site.)

The embedded Flash file is passed the domain name so that it can go out and look up the presentable name for display in the Flash file. The Flash file then makes a call out to the seal server and gets the name. If the domain name is invalid, it sends back the same variable name but this time with an empty value. This theoretically prevents you from passing the organization name into the Flash file in the same way the domain name was passed into the file. In the end though, this doesn't actually prevent anyone from being able to pass in custom data into the Flash file.

What I did:
To demonstrate the weaknesses in this particular approach, I needed to give the best appearance of this being a legitimate seal. The best way to do that is to embed the seal using standard Flash object/embed tags. I then also placed a completely innocent looking Flash file on the page. Currently this file has an input field that allows you to change the seal name as you wish, but if I were doing this to really look legitimate, it could be something completely innocuous, such as the logo for the page.

This second file has javascript calls in the form of getURL commands. These javascript calls initialize the splash function (the function that runs when the seal is clicked), and make calls to the seal Flash file setting a variable. It then sends the Flash file's timeline to the appropriate frame to play and display the seal name. By encasing the javascript in the Flash file, there is no easy way for the average person to even know that I am tinkering with the seal file. It would be entirely possible to have run the javascript from the page itself, but that would have made the HTML for the page look much messier, and therefore less convincing.

The verification page is just a file sitting on my server that replicates the verification page on VeriSign. I removed the address bar and other browser features so that the location from which the page was called would not be a giveaway. I've kept most of the page content just as it appears -- making a few changes just for humor's sake. But that page could have easily been a convincing forgery, up to and including translation pages, a fake "Report Abuse" page, and other elements.

As a last note, this will not work on all environments, but should work on most. If there is a problem though, the VeriSign logo should still come up, but the name and the Click to Verify message will not be displayed. With a bit more work though, support for multiple environments would not be too difficult.

General Seal Issues:

• The .swf file is Flash 5, but the HTML sent by VeriSign is Flash 6: While this file would run on your system if you have Flash 5, the HTML will still try to get you to upgrade to the latest version of Flash. Many enterprise sites are just moving over to Flash 6. Inevitably, some corporations will place this seal on their site and every visitor to the site will be forced to upgrade to Flash 6. This will be problematic for many sites.
  
• The variables are placed in predictable places:   My code was able to work because I was always able to store a variable in the right place. If the data had been accessed in a movie whose name was dynamically assigned with attachMovie, and perhaps based on a random number or timestamp, I would have had a far harder time overwriting the variable. (Perhaps VeriSign can find somebody who is handy with numbers to tell them how such a thing might work.)
  
• The "Click to Verify" calls a javascript function: Having the verification link call javascript out in the HTML means that anyone stealing the .swf can easily divert the verification page.
  
• There are no scripts to check the data over time for changes, such as the ones made here: A script that runs periodically could watch the variable for changes in its value. If the value changes, the script could remove the _root timeline, clearing out the whole movie (a "self destruct" feature).

This article was written by Justin Everett-Church on Nov 9, 2003 (Email)