Keeping an Eye on Adobe Flash Security Means Catching Common Programming Errors

With hackers increasingly targeting Web 2.0 sites, knowing how to develop secure Adobe Flash applications can be a difference maker when it comes to avoiding mass compromises.

It is not surprising then that some are calling for developers to pay closer attention to Flash security. IBM, for example, just enhanced its AppScan tool to add the ability to test and scan Flash applications.

At the ShmooCon 2009 conference in Washington, D.C., Hewlett-Packard’s Prajakta Jagdale used her presentation Feb. 7 to focus on common vulnerabilities in Flash applications. In her research, Jagdale found that many developers leave, for example, uninitialized variables that leave applications open to cross-site scripting.

But as she noted in an interview prior to the conference, many of the common security holes—from input validation to having user name passwords hard-coded inside of the client code—are not exclusive to Flash.

“These are the general principles that are security principles that are applicable to any sort of technology language,” said Jagdale, research engineer with the HP Web Security Research Group.

Earlier this year, the SANS Institute teamed with a number of experts to produce a list of the top 25 most dangerous programming errors. That effort involved people from more than 30 organizations, including Symantec, McAfee and Microsoft. 

The idea was that publicizing a list of the most common problems will cause buyers to exert more pressure on software vendors to certify that their code is free from those errors.

The certification, the authors contend, would put responsibility for the errors and any damage they cause in the hands of the software vendor.

"There appears to be broad agreement on the programming errors," SANS Institute Director Mason Brown said at the time in a prepared statement. "Now it is time to fix them. First we need to make sure every programmer knows how to write code that is free of the Top 25 errors, and then we need to make sure every programming team has processes in place to find, fix, or avoid these problems and has the tools needed to verify their code is as free of these errors as automated tools can verify."

Whether or not buyers actually start to put pressure on vendors, avoiding common mistakes like the ones on the list or those mentioned by Jagdale protects us all in the long run. Certainly, there is no shortage of sources out there for information regarding best practices. Adobe, for example, offers a number of resources for developers looking for guidance on creating secure applications, Jagdale noted.

"All these recommendations are provided by the vendor ... and whenever developers start developing any applications they should make sure they read the recommendations there," she said.