To wit, there are essentially four types of cross-domain loading mechanisms:Cross-domain data loadingData loading means you are actually importing data from another site… in other words, your code has access to the actual bits. This includes operations such as loading XML files, accessing the bits of an image or sound file, importing code into your sandbox, connecting via a socket, etc. In this scenario any content loaded is imported into the loader’s sandbox.Cross-domain data loading is governed by cross-domain policy files, commonly known as “crossdomain.xml”. Crossdomain.xml allows a server to specify other domains from which SWFs are permitted to load cross-domain data from it.Cross-domain data loading is something that is generally not directly possible in browsers today, since they don’t provide a mechanism to express cross-domain loading permissions like crossdomain.xml. The only significant exception to this is cross-domain script importing (i.e. SCRIPT SRC=). Why is universal cross-domain script importing ok, but no other cross-domain loading data mechanism? I have no idea, someone back in the day decided that it was ok.Cross-domain content loadingThis is the concept of loading cross-domain content in a hands-off fashion. For example, you can currently load and display images & play other SWFs and sound files cross-domain. This does not require any cross-domain permissions.So how is this different from cross-domain data loading? Its a hands-off loading operation, which means the loadee content in question can be displayed to the user, but the code that loaded it has no access to its bits. So you can’t script into it or inspect its bits because it remains in its original context.This model is the same in the browser… you can load images or iframes across domains, but you cannot inspect them or script into them.Cross-domain SWF->SWF or HTML->SWF scriptingA SWF can specify other domains from which SWFs or HTML are permitted to script into it. Scripting is not governed in any way by crossdomain.xml.It requires calling an ActionScript API: System.security.allowDomain()Cross-domain SWF->HTML scriptingSWF to HTML scripting is governed by the allowScriptAccess OBJECT/EMBED parameter. It defaults to “sameDomain” which means that SWF is only allowed to script into the surrounding HTML content and browser when it comes from the same domain as the HTML hosting it.

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

For the sake of simplicity, lets assume that the SWF-based ad and HTML-based container are hosted in separate domains, and that you have control over the HTML container.At this point a short review of the potential threats posed by an advertisement is in order. An ad might try to:1) Automatically redirect the user to another site2) Redirect the user to another site after clicking on it3) Automatically open a new window to another site4) Open a new window to another site after clicking on it5) Automatically install a malicious programFor each one of the above threats, here are the available mitigations respectively:1) and 2) Set the allowScriptAccess=”never” parameter of the OBJECT/EMBED HTML tag to prevent SWF content from controlling existing browser content, including preventing redirects of existing content3) The Flash Player uses the browser’s existing pop-up blocker logic to prohibit pop-ups triggered from Flash, assuming the browser’s pop-up blocker is enabled4) This is normal behavior for an ad. Much like HTML/JavaScript, if the user clicks on a link to go to certain website, generally this action is permitted (though it can depend on how aggressively your pop-up blocker is configured). Furthermore, the hosting HTML could even prohibit this entirely by setting the allowNetworking=”none” or allowNetworking=”internal” OBJECT/EMBED parameters, though this will prevent users from clicking-through advertisements altogether, and so is generally not the desired effect5) Flash Player does not permit automatic downloads; any downloads require user involvement and consentTo an advertiser or hosting website, this all may seem rather complicated, but in fact it boils down to one straightforward change assuming you want to have ads that:- disable any redirects or automatic opening of new windows- allow a user to click-through the ad to open in a new windowJust set the allowScriptAccess=”never” parameter on your OBJECT/EMBED tags.One caveat: this does not prevent an ad from opening a window to a potentially malicious website if a user clicks on it. There is no technical mitigation to that problem, as its impossible to tell whether the website the user is about to visit is malicious or not. So there will always be a degree of responsibility the publisher of the ad needs to accept for ensuring that they only accept content from trustworthy partners.If you instead want to have ads that prohibit any browser or network interaction, even if the user clicks on them, you can set the allowNetworking=”none” parameter instead.Keep in mind that it is possible to include potentially malicious JavaScript in the OBJECT/EMBED parameters themselves. While not an issue with Flash Player itself, you need to be careful when validating any HTML tags or parameters for undesirable code.Like any change, you should thoroughly test any such modifications to ensure your content will still work. For example, the recommended solution above requires ads to open new windows, rather than redirecting the existing window.References: please see my previous blog entry about controlling SWF content from HTML.

On the face of this, this seems like a reasonable assumption to make. Simply adding system access to a browser sandbox would indeed be much scarier, but that is not what happened. In fact, AIR Application sandbox is significantly different from a browser sandbox insofar that many high-risk APIs have been disabled or severely restricted, making it far more difficult to attack such applications. So the AIR sandbox is not weaker than a browser sandbox; it is different, and in many respects stronger.

Code injection (aka cross-site scripting or XSS), essentially happens because applications fail to validate all data to ensure that no code can be included. Injection happens when code gets turned into data through a variety of different APIs. It can also happen when the developer imports code (such as using the SCRIPT tag for JSON loading) but for some reason assumes that they are only loading data.What we have done in AIR is to identify those API’s and either prohibit or severely restrict their using at application runtime. For example, a partial list of things prohibited in an AIR HTML Application sandbox:* Calling the eval() function.* Using innerHTML properties or DOM functions to insert script tags that load a script outside of the application directory.* Using innerHTML properties or DOM functions to insert script tags that have inline code (rather than loading a script via the src attribute).* Setting the src attribute for a script tags to load a JavaScript file that is outside of the application directory.* Using the javascript URL scheme (as in href=”javascript:alert(‘Test’)”).* Using the setInterval() or setTimout()method where the first parameter (defining the function to run asynchronously) is a string (to be evaluated) rather than a function name (as in setTimeout(‘x = 4′, 1000)).* Calling document.write() or document.writeln().For a more comprehensive treatment of the HTML sandboxes, please see the HTML security section in the Livedocs.Similar restrictions have been placed on Flash content, however the Flash model is generally more resistant to injection attacks (as there are very few APIs that can turn data into code) so fewer changes were required.Of course the Application sandbox is not the only sandbox present in AIR. In fact only content originally installed with the application should be placed in the Application sandbox. All other local and remote non-application content is placed into the same equivalent Flash or HTML sandbox that it would be in the browser. Click here for detailed information on sandboxes in AIR.

AIR lets web developers–whether HTML/AJAX, Flex or Flash–build rich and complex applications that run on the desktop. From a security standpoint, the “desktop” part of that is the key.

If you come from a web development background, you find that desktop applications differ significantly security-wise from apps based in the web browser. Desktop applications have direct access to the local system (insofar that the operating system permits, of course), but in return they must be explicitly installed by the user or system administrator.

Adobe requires all applications on Adobe AIR be digitally signed, by either a self-signed or commercial certificate from a trusted Certificate Authority (CA). For the end-user, when an application is signed with a self-signed certificate the installation experience will reflect that the publisher is unknown, giving the user pause as to whether they should continue. So, when developers use a commercial certificate from a trusted Certificate Authority users are more likely to install applications. We’ve worked with trusted Certificate Authorities such as Thawte (www.thawte.com) to make it easy to get a digital certificate for code signing. We’ve also enabled administrators to block applications that do not have a signature that chains to a trusted CA.In AIR, we provide a consistent installation experience for all of our supported platforms (Windows, OS X and soon to be Linux). This means that the user is always presented with the same installation dialogs regardless of which application they are installing or the particular platform that they are on. For some additional information on the AIR installation experience see my previous blog entry.Just because AIR applications are bound by the desktop security model, it doesn’t mean that you don’t have to think about security. On the contrary, desktop applications require as much consideration as web applications. This is something we put an enormous amount of effort into. For example, AIR applications have multiple security sandboxes to allow them to interact safely with content on the web.For an overview of the Adobe AIR security model, see the AIR Security White Paper which outlines the security model and provides information on the security sandboxes available to Adobe AIR applications. We’ve also put together another white paper which specifically details the enhancements to the HTML security model to enable applications on the desktop.If you are developer looking at AIR, a great next step would be to check out my introduction to the AIR security model at the Adobe Developer Center.

A common scenario:

You need to log into your bank / credit card / mortgage company. You go to http://www.pickabank.com, 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?

Wrong, of course.HTTPS (usually SSL or sometimes TLS), is used for two reasons:a) Authentication (of server and occasionally client)b) Encryption (of bi-direction communication)The goal of those is to ensure that, respectively:a) You are really talking to whom you think you areb) The content has not been modified or inspected en-route by a 3rd partyWhich means that if you are interacting with a page that is served over HTTP instead of HTTPS (even if it is your bank’s homepage):a) You don’t know who you are really talking to. It could be your bank, it could be a man-in-the-middle attacker, it could be anyone at all.b) You don’t know if the content has been modified en-route (injected with a malicious payload, or just modified to send your credentials to the attacker’s server rather than the bank’s).In fact, short of inspecting every bit of HTML, CSS and JavaScript that comprises that page (including all the stuff it loads dynamically), you can’t be at all sure of where your credentials are being sent… even if the form destination URL seems legitimate it could be overwritten on the fly by JavaScript at submit time or via redirects.Which means that little padlock icon next to the submit button is worse than useless. In fact, it trains the user to believe that are doing something safe when that is far from the truth. Same for any “hacker proof” iconography. The only icon that matters is the padlock in the browser address bar.So as a developer, what can you do? Simply, ensure the very first communication the user has with your website is secured via HTTPS. If the first interaction with your site is not secure, how can any subsequent interaction be secure? You could try using redirects to HTTPS, but any smart attacker will simply modify those pages on the fly to remove the redirection to HTTPS, and leave the user insecure.Honestly this is simpler advice in theory than practice. For truly sensitive websites like banks, the above approach is the only acceptable design, with the caveat that the user will usually not try the HTTPS:// URL by default. So you will need to redirect all HTTP requests to their HTTPS equivalents. This still opens an attack window during the redirect, but hopefully the user will bookmark the HTTPS homepage afterwards and link to that directly. Some browser URL auto-complete features will now remember the final (redirected-to) URL instead of the initial one, which can also provides a measure of protection.Still, at least you have avoided committing the cardinal sin of serving a login page over HTTP. Or worse yet, FORCING the user to HTTP for the home page login, as some large banking sites still do… those get an “F” (how that can pass a real security audit, I’ll never understand).But outside of banks, healthcare and other very sensitive websites, many websites have largely non-sensitive public content, and then maybe a small online store that has to be secured. At some point the user may have to switch from HTTP to HTTPS. This is a real bummer. All you can do then is to ensure you provide (and redirect to) an all-HTTPS login screen and shopping cart / checkout process. But be aware this is a poor compromise compared to providing the entire session in HTTPS.As an aside, I’ve frequently encountered skepticism and misconceptions of these sorts of man in the middle attacks and associated costs of mitigation:- Man in the middle and similar injection attacks are very difficult to execute and mostly hypotheticalFact is, man in the middle attacks are pretty easy.In a coffee shop, airport, hotel or similar public wireless environment, they are trivial. Its common to see fake AP’s like “Free wireless access”, hoping to lure a poor sucker into associating with a hacker’s access point. At which point its simple to change DNS information, or to inject packets. However, toolkits also exist to inject code via wireless packets even when associated with a valid open access point, making the attack trivial through no fault of the user (other than not insisting on HTTPS). Without HTTPS, no interaction in these public wireless environments is remotely safe.Even when using a home network via ethernet cables or WAP-protected wireless networks, system compromises of ISP infrastructure are relatively routine (especially smaller ISPs that don’t invest as much into security). Attacking DNS servers to reroute banking and financial services requests to the attacker’s servers is a very attractive phishing attack, and impossible to detect without HTTPS.There are a plethora of related network attacks such as ARP and DNS poisoning that can redirect a user to the wrong server.- SSL is expensiveHardware SSL accelerators are pretty inexpensive lately and reduce any performance impact to a negligible amount. Have an all-SSL site decreases the development and testing cost of managing all those HTTP -> HTTPS redirects.

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.

One sandbox, called the “Application” sandbox, permits direct access to all AIR APIs, but in return restricts certain dangerous practices and APIs such as eval(), and related dynamic script generation techniques at runtime. This means that any code in this sandbox is far less vulnerable to typical web application attacks, such as XSS and related injection and escalation of privilege attacks. This also means that many existing applications and frameworks may not work entirely in this sandbox without modification.The other sandbox, which we are referring to as the “Classic” browser-like sandbox, behaves largely like existing remote content in the browser, allowing you to use all of the dynamic scripting techniques you are used to, but in return without direct access to system AIR APIs.For interaction between the Application and Classic sandboxes, we have the Sandbox Bridge, which is essentially a pass-by-value serialization mechanism for interacting between sandboxes that don’t trust each other.One way to look at this is to think of the Classic sandbox as the typical browser sandbox for web content, while the Application sandbox behaves as the server, doing a lot of the heavy lifting and sensitive operations. As in the web model, content in the Application sandbox should not trust the content in the Classic sandbox, and should not expose any low-level system API’s to it via Sandbox Bridge.If your application relies on existing frameworks or dynamic script generation, there is a very good chance it will need to be updated. If you see the message “Error: Parsing Disallowed”, then AIR is reporting back that you are running eval() or a dynamic script technique in the Application sandbox after loading is complete. If that happens, you need to either modify that code or move part of your application into the Classic sandbox by defining a new frame or iframe with special attributes. See the FAQ below for details on how to migrate your application.In the short run, we expect that initially many apps will be ported to work within the Classic sandbox, then over time migrate most of their code over to the Application sandbox. But many other patterns will emerge over time, and one of our primary goals is to obtain feedback on this model, and iterate in future releases.If you are at MAX in Chicago this year, check out the AIR and Flash Player security talks, as well as the AJAX Security Panel!For full details, please see the following links:HTML security model FAQ: http://labs.adobe.com/wiki/index.php/AIR:HTML_Security_FAQHTML-based sample applications such as Fresh, Bee, Drag’n Share, PeekAgenda, and Podcast Player: http://www.adobe.com/go/air_samplesBuilding an expense tracker on the new Adobe AIR HTML security model: http://www.adobe.com/devnet/air/ajax/articles/expense_tracker.htmlThe security chapter in the developer docs: http://labs.adobe.com/wiki/index.php/AIR:DocumentationFinally, for a general overview of AJAX security concerns, also see: http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.html

The install experience for an AIR application has been the subject of much effort internally, and many questions externally. One of the common questions revolves around the relatively “scary” nature of the installation dialogs.

One of the goals of the installation experience is to accurately communicate to the user the potential risk of installing AIR applications in general. An AIR application is a fully privileged local application, with similar powers and risks to a native application–including full filesystem read/write access. As such, the danger is that developers, IT administrators, or users could assume that AIR applications are somehow intrinsically “safer” to install since they are based upon web technologies.

One way a developer can improve the installation experience for the user is to sign the AIR installer file with a commercial code signing certificate. To see the difference in the installation experience for such an application, check out the “Employee Directory” sample AIR application here: http://labs.adobe.com/technologies/air/samples/

In the future there may also be more restrictive sandbox types that provide a “safer” type of AIR application, with a corresponding installation experience to encourage developers to develop applications with the minimum level of necessary privilege.

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 http://www.adobe.com/devnet/flashmediaserver/articles/protecting_video_fms.pdf

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.

“allowScriptAccess” controls the ability of the SWF to call into the browser’s JavaScript DOM. This means the SWF could inject script into the website that is hosting it, which can be either dangerous, or at least not desirable (as the SWF could open new windows, inject JavaScript into the surrounding HTML, redirect the current window, read cookies, etc.)”allowNetworking” affects the ability of a SWF to perform network I/O, either via the browser (opening new windows, etc.) or directly using Flash networking APIs. This implicitly may also restrict scripting access to the browser, as you cannot prevent network I/O without prohibiting access to the browser’s JavaScript DOM.In order of least to most restrictive, you can specify:”allowScriptAccess=always”: This permits the SWF to call arbitrary browser JavaScript at all times, even if the SWF came from another domain. This is generally not safe to do unless you completely trust the SWF you are loading (and any children SWFs it may subsequently load).”allowNetworking=all”: All normal network I/O is allowed (as permitted by the Flash Player security model).”allowScriptAccess=sameDomain”: This permits the SWF to call into the browser’s JavaScript DOM only if the SWF came from the same domain as the HTML hosting it. This is equivalent to the typical browser “same origin policy” model.”allowScriptAccess=never”: The SWF is never permitted to call into the browser’s JavaScript, even if it came from the same domain as its HTML container. You can use this tag if you host SWFs in the same domain as the HTML, but don’t trust the SWFs to interact with the surrounding HTML, cookies, etc. In particular this setting will also prevent the SWF from modifying or redirecting existing frames windows. However, if you really don’t trust the SWF you may need some stronger medicine.”allowNetworking=internal”: Everything with “allowScriptAccess=never” applies, and also prevents the SWF from opening new browser windows, modifying existing ones, or otherwise affecting any browser state. The SWF can still use internal networking ActionScript APIs like loadMovie(), XML.load(), LoadVars, etc.Finally, “allowNetworking=none” prohibits any browser or network interaction. This means that the SWF cannot do much more than interact with the assets it contains internally, and cannot do anything to influence the browser, or load or send any data over the network.In addition, Flash Player integrates with the browser’s pop-up blocking technologies to ensure that windows that could not be opened directly via HTML/JavaScript will be blocked in Flash as well.The safest strategy is to always explicitly set the parameter value you want, so you don’t have to worry about what the behavior will be on a given situation.For additional details on the allowScriptAccess tag, see http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.htmlFor additional details on the allowNetworking tag, see http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.html

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.

By providing a cross-domain policy file, a website can specify which parts of it should be accessible, and to content from which other websites. If a cross-domain policy file is located at the root of the website (the default location the Flash Player looks in for cross-domain policy files is “/crossdomain.xml”), then it controls access to the entire site. If it is placed in a sub-directory, it only controls access to that subdirectory and below.So if your website hosts only data intended for public consumption, isn’t behind a corporate firewall, and does not protect any data via cookies or other browser-based user authentication mechanisms, then you can deploy a policy file that permits access from “*” (anywhere) in your root folder.If you want to permit content from only certain websites to load data from a given server, then you could specify only those websites in your policy file. For example, if http://www.a.com and http://www2.a.com need to load data from http://data.a.com , then you would create a policy file at http://data.a.com/crossdomain.xml that would include “www.a.com” and “www2.a.com”, or alternatively, simply “*.a.com”. The server that is providing the data always hosts the policy file that controls access to its data. No other server can do so on its behalf. Here is an example crossdomain.xml:<?xml version=”1.0″?><!– http://www.adobe.com/crossdomain.xml –><cross-domain-policy><allow-access-from domain=”www.a.com” /><allow-access-from domain=”www2.a.com” /></cross-domain-policy>If on the other hand you want to only expose specific parts of your website to the whole world, then you can place a policy file containing “*” in the specific subdirectories that you want to expose to the world. You may also expose certain subdirectories only to content from specific servers, etc. The principle of least privilege implies that you should only expose the parts of your website that you really need to, and only to the minimum number of other websites.The general best practice for deploying policy files is to have separate servers. One, such as http://www.a.com, as a regular web server without any cross-domain policy files, and then another, one such as http://api.a.com, that hosts only data intended for public consumption and does not utilize any browser-based (i.e. cookies) user authentication mechanisms.There are many other permutations of this mechanism, that may or may not be applicable to your particular architecture.For example usage of cross-domain policy files, see: http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001085.htmlFor a detailed description of cross-domain policy file best practices, see: http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html