Posts in Category "Web Security"

Cross-Domain 101

I have noticed some confusion around the different cross-domain loading mechanisms in Flash Player. Its a complex topic, so I figured I’d put together a 90 second primer on the differences.

Continue reading…

Flash and Advertising

Some concerns have been raised lately regarding malicious ads using Flash. The good news is there are already mechanisms in the Flash Player to effectively address these concerns.

I am simplifying here, but there are two main goals for web-based advertisements:
* advertisers want to present compelling, engaging advertisements
* advertisers want users to click through to their websites

Continue reading…

Don’t be SSLy!

One of my pet rants is on SSL, or specifically the inappropriate use of SSL on large websites. This is hardly a novel problem, yet even Fortune 500 bank websites continue to make this glaring mistake on their homepages.

A common scenario:

You need to log into your bank / credit card / mortgage company. You go to, and up comes their home page with a typical login panel (“Login:”, “Password:”). The URL is still HTTP but there’s a nice padlock icon next to the “Submit” button, and lots of “Hacker safe” iconography everywhere. Having confidence that the site is truly “safe for hackers”, you enter your information and hit submit. Right?

Continue reading…

HTML Security in AIR

I haven’t posted anything for a bit, as we’ve been very busy in the kitchen! We have a new Beta of AIR available, just in time for MAX. Check it out at

My focus for this AIR beta has been HTML security. In AIR, you can build applications in just Flash, or HTML, or a combination of the two. The unique challenges of current design and implementation patterns in AJAX make HTML an especially interesting platform for desktop applications from a security perspective.

Already risky patterns, such as rendering of untrusted content in innerHTML, eval() of remote script & JSON data, and reliance on javascript: URIs, become more dangerous when they intersect with the system privileges inherent in AIR. To address the threats resulting from this model, we have separated application content into two sandboxes.

Continue reading…

Flash Media Server, RTMP and Sandboxing

In response to previous questions regarding FMS security, the reasoning behind the restrictions on interacting with RTMP streams is to protect the content being provided by the server. This is a little different from other data loading operations as RTMP is not directly covered by cross-domain policy files and was not originally intended as an interactive data source (rather than just a hands-off media type).

In theory permitting access to the RTMP stream does not pose security issues so long as the Flash Media Server can reliably specify a preference for who is permitted to interact with the RTMP streams. So don’t be surprised if this restriction is relaxed in the future.

For detailed information regarding protection content served from Flash Media Servers, see

How to restrict SWF content from HTML

When you host SWF content inside HTML, you have a few tools at your disposal to control how much privilege that SWF has. If you are hosting SWFs that you created or trust completely, these may be unnecessary, however you may find them useful otherwise.

When specifying container tags (i.e. OBJECT or EMBED), you can optionally provide one of the following two parameters: “allowScriptAccess” and “allowNetworking”. These tags can only be specified within HTML (not from a SWF itself), and apply to that root SWF and any other SWFs the root SWF may load.

Continue reading…

Cross-domain policy files

Today I’d like to take a shot at summarizing the reasoning behind having cross-domain policy files in Flash Player, and some best practices related to implementing them.

The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the “same origin policy.” Note that this policy does not prevent the displaying of HTML or media assets cross-domain, such as HTML in an IFRAME or other images, etc. This is also true in Flash Player.

So how did cross-domain policy files in Adobe Flash Player come about? The rationale is that sometimes its perfectly ok to permit cross-domain loading of data, such as when the data isn’t protected by a session-based login or a firewall, and is intended to be accessible from other websites. Currently, the only way to do this inside JavaScript is by using the <SCRIPT src=…> script importing syntax, which is inherently dangerous.

Continue reading…


In the realm of security, “trust” is generally defined as “something acting the way you expect it to act.” By that definition, URI schemes ( have a checkered history at best.

Many developers tend to assume that a URL simply refers to a network data loading protocol, such as HTTP, HTTPS, and FTP. However, it been extended over time to include:
– local file I/O (file:)
– network file I/O (smb:, nfs:)
– local application integration (mailto:, various IM & streaming media schemes)
– local operating system integration (generally very dangerous stuff like shell:, vshelp:, local:)
– actual code generation/injection schemes that can create JavaScript within the browser (javascript:, data:).

Flash in particular also supports the asfunction: scheme, which can be used to call local ActionScript functions within your SWF.

If you are building an application that handles URLs, you should be aware of your responsibility to ensure that any URLs that are passed to the application and acted upon–either by having the application loading it directly or by the user clicking on it–are handled appropriately.

Continue reading…