More on Flash security – why Adobe needs technical editors and copywriters
About a year ago, Adobe’s Peleus Uhley provided a 13-page Creating more secure SWF web applications article for the Developer Connection website.
The background information is probably the most interesting and comprehensive on what the Flash Player team has had to deal with as far as bizarre security breaches we would never expect:
Malicious data injection
…it is common for FlashVars to be set via the Object tag within the HTML. However, developers sometimes forget that these variables can be set via the URL where it is trivial for an attacker to alter the values. For example, if the FlashVar value is a URL that points to remote content such as another SWF, then the attacker could alter the URL to point to a malicious SWF instead. In ActionScript 2.0, any un-initialized value can automatically be set via the URL as a FlashVar.Script injection into the browser
The most common vulnerability to consider is an attacker injecting data in order to conduct a cross-site scripting (XSS) attack. Assume that the target SWF takes a URL value from a FlashVar and sends that information to a navigateToURL or a getURL command. An attacker who notices this behavior may try to replace the original URL value of the FlashVar with a “javascript:” URL. JavaScript URLs sent to the browser through getURL or navigateToURL methods will execute within the context of the domain hosting the SWF.
These are just a couple of the more complex, yet controllable security issues we now face with Flash-based web apps (although if you really did read them, you’ll see they’re essentially the same issue, duh).
There’s other scenarios and solutions listed such as duh-obvious “use HTTPS, not HTTP for passwords” as well as long explanations on stuff that fall way beyond the need-to-know for Flash peeps: “If the target website utilizes atomic (single submit) actions for updates to user information, then the attacker can initiate a change to the user’s account on that site by forcing the browser to make a request to the site.” (Atomic? Really?)
Whenever I’m filled with the need to rant, I feel it’s best to balance with a positive note. In this case, Adobe does provide a ton of in-depth information on Flash player security and creating secure SWF web apps, and so it’s possible to go back over time and study each of these “necessary” approaches for safety.
But I can’t help but point out the lack of summary, instructional aid, example, or “just do this” which is mandatory to a multi-user-level product such as Flash. The missing link here is Adobe leadership passing-the-buck on communication to their primary user base: creative developers who actually buy and use CS4 (as opposed to programmers who instead opt for the free Flex SDK with free Eclipse).
I feel terrible having to point stuff like this out, but it seems clear that in many cases, Adobe’s programmers are burdened with the responsibility for communicating complex solutions that are obviously far over the heads of Adobe communications and management and thus presented to the public in rambling “hacker-speak” without the help of an experienced technical editor or copywriter. This raw data is (mostly) fine if you’re a programmer, but Flash designers / animators are left scratching their heads and utilizing allow-domain “*” solutions.
In this case the article is listed as Intermediate user level. Coming from Uhley’s technical background, I’m sure that’s a fair assesment, but articles like these are far too dense for creative Flash developers.
Of course I could be wrong — I’m sure it’s possible Uhley is also a CS4 user and has our same fundamental understanding of Illustrator, Photoshop, and stuff like inverse-kinematics, interface design, squash and stretch, and color theory.
After all, that’s just beginner Flash stuff.
