Radley Marx

Inaugural Noobs

You’re important enough to be two seats away from the swearing-in of the most historic new presidential figure in US history.

Do you:

a) display honor and respect for this historic occasion?

b) pull out your iPhone and “capture the moment” like a Jersey tourist?

 

(my rant for the week…)

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.

Adobe’s Flash security too dense… for Adobe?

OK, I’m not sure how or why this is happening, but I’m now seeing Security Sandbox errors in my debug player whenever I *launch* CS4’s Flash IDE:

*** Security Sandbox Violation ***
SecurityDomain 'http://www.adobe.com/startpage/fl.swf?&lvl=1&ver=10.0.0&plat=mac〈=en&stat=full&spfx=PF' tried to access incompatible context 'file:///Masuimi%20Mac/Users/radley/Library/Application%20Support/
Adobe/Flash%20CS4/en/Configuration/StartPage/StartPage.swf'

So what’s this error? This is for the welcome menu that appears when you launch Flash.

Instead of being part of the actual application, Adobe uses a server-based swf file for the welcome screen. They probably do this so they can roll out timely information updates and promos (like “Take a feature tour” above).

The good news is that it doesn’t crash Flash. The neutral news is that I quickly max out on 100 Security warnings in my debug window. The bad news is Adobe is demonstrating to Flash developers that even Adobe’s internal development team doesn’t get what’s going on with Adobe’s obtuse security plan.

Flash security has changed *dramatically* in the past year for good reason. But those changes are clearly not documented and propagated effectively. Just by putting together this rant article I’ve discovered three more random articles on Flash security. Out in the real world, I’m seeing Flash Security Sandbox Violations pop-up all over the place, most commonly in embedded videos from YouTube and Vimeo (which I have many embedded on vj.tv).

I certainly didn’t expect to see this issue within Flash itself. I think whoever is directing Adobe’s Flash/Flex program needs to take a step back and rethink their overall communication strategy.