Before jumping into a discussion of the design and development phases, it is important to consider how your Flex application will be viewed by the end users and how it affects security. Because your Flex application is compiled to a Flash SWF file and usually (though not in every case) deployed over a network, the majority of security concerns lie on the Flash Player itself. With this in mind, it is important to mention that there are ways to structure your data and work with the Flash Player that will help you create a more secure application. This section takes a look at network security concerns, open technology concerns, and what security features are available to you through the Flash Player.
Network Security Concerns
When building an Internet application in Flex (or any API, for that matter), network security shouldn’t be overlooked. Your goal is to keep sensitive data out of the public view. This may sound easy, because the average user would never be able to see how you’re loading data from XML or through AMF, but third-party tools have made eavesdropping easier for even your basic user. This is called a “man-in-the-middle attack.” The user is able to read and possibly modify data being sent from the server to the Flash Player client (in other words, your application). The following paragraphs discuss two common methods of reading data and their respecitive vulnerabilities.
You will more than likely use (or have used) XML to store data for a Flash or Flex application. Once it is up and running, it is a very convenient way to store groups of data that can be easily updated. However, XML is not a good place to store sensitive data, because XML is transferred over HTTP/SOAP and is encoded as Unicode or ASCII. This makes it immensely vulnerable.
Using your preferred browser, type in the URL to the location of your XML file (such as http://myserver/assets/myXML.xml). With any luck, your Web browser will display your XML, and some browsers will show you if your XML is malformed. If it didn’t display it immediately, but did load the XML file, go to View 
Source within the Web browser’s menu. If you can view your XML that is stored on the server, so can anyone else. You’d like to think most people would never try to look through your XML, but people are curious and sometimes malicious. Using a third-party program such as Sothink SWF Decompiler, someone could easily peek under the hood of your SWF and copy the URL to your XML. Even easier, someone could use a third-party HTTP header viewer such as the Tamper Data add-on for Mozilla Firefox to see what files are being requested. Such methods would give away the precise location of your XML file, allowing anyone to view its contents.
Flash Remoting and other remoting services that use Action Message Format (AMF) are a little more secure, but not a perfect solution. “Secure” is probably not the best term. Because AMF is a binary format, it is harder for the average user to view and interpret. Many developers, however, use middleware programs such as Charles by xk72 (http://www.xk72.com/charles/) or Service Capture by Kevin Langdon (http://kevinlangdon.com/serviceCapture/). Both programs act as a proxy between the server and the application. They parse data formatted in AMF and display it in their GUI. Such programs are convenient for developers, and are often lifesavers during the development process. But because the developer can view the data, so can anyone else who happens to be running these programs. Again, your average user probably is not running programs like these, but because they exist, you have to assume someone probably does.
So how do you avoid this? The safest route is to limit sensitive data altogether. If you are developing an application that requires large amounts of sensitive data to be passed to and from your application, it is recommended that you use encryption, such as Secure Socket Layer (SSL), through the browser. Using SSL encrypts the SWF file as well as data being sent over HTTPS, ensuring both the host and the client that their data is secured.
The other option for encryption is to use a cryptographic algorithm, such as MD5 or SHA-1. Flex does not natively support cryptographic encryption, but MD5 and SHA-1 libraries are available on Google Code as part of the AS3 Corelib, by Adobe (http://code.google.com/p/as3corelib/).
Open Technology Concerns
As with any open Web technology such as HTML and JavaScript, there is a certain degree of sacrifice that you must understand before deploying your application. Web applications that use server technologies, such as ASP, J2EE, or PHP, have an extra level of security that Flash lacks. When the user queries an application created in ASP or something similar, the server interprets the script and displays only the HTML necessary for the user to operate the application. The server hides all sensitive code from the user, and it is virtually impossible to view, unless you have the authorization to do so.
In the case of applications created in Flex or Flash and deployed as SWFs, clients download the application SWF directly onto their computers. This allows users complete access to your SWF, and it also allows them access to download any additional SWFs and supporting media that are called by your application. The redeeming part of using SWFs is that it takes third-party software to view your source, making it more difficult for most users.
Because your SWF is downloaded to the users’ machines, it is recommended that you rely on the server to validate sensitive information such as usernames and passwords. It is all right to check character length and integrity from within Flash, but as far as encryption and validation go, it’s better to store this on the server using a server-side technology, making it more difficult for people to gain access to that information.
Flash Player Security Features
As mentioned earlier in this section, Flash Player handles the bulk of the security for your Flex application.
Flash Player’s main mode of security is through sandboxes. A sandbox is a security grouping that limits the Flash Player’s access to certain resources. The following table describes the four types of sandboxes.
Open table as spreadsheet
| Sandbox |
Description |
| Remote |
By default, when a user downloads an SWF from a Web site, it can only access SWFs within the parent domain, or domains specified within the Security.allowDomain() or crossdomain.xml file. |
| Local-with-filesystem |
This allows an SWF executed in Flash Player locally to access the local filesystem. However, because the SWF is not trusted, it cannot communicate over a network. |
| Local-with-networking |
This allows an SWF executed in Flash Player locally to access a designated Internet URL. However, because it’s not trusted by the user, it cannot read from the local filesystem. |
| Local-trusted |
The local-trusted sandbox allows users or administrators of a machine to place an SWF into the “trusted” sandbox. When an SWF is trusted, it can access data over the network and on a local machine. Again, this must be set by the user or the machine’s administrator. |
Flash Player’s method of security is fairly straightforward. When users access a site that contains a Flex application, they are downloading the SWF onto their computer. At that point, Flash Player sets up a security sandbox that limits the data being sent and received to only media that is within the domain of origin. For example, if you, as the developer, would like to access and manipulate an external SWF from your application using <mx:SWFLoader>, you can do so if it fits the following criteria:
- The SWF was created for Flash Player 9, meaning it is coded in ActionScript 3 and not ActionScript 2 or below.
- The SWF is within the same domain as the parent SWF trying to access it. If your application is at the domain http://www.domainA.com/, it can access child SWFs contained within that domain (such as http://www.domainA.com/swfs/SWF_2.swf).
However, both rules can be broken. If you need to load legacy content, such as content created in Flash 8, you can use the LocalConnection class. If you need access to an SWF outside of your domain, you can grant access to it using Security.allowDomain() or by editing the cross-domain policy within the crossdomain.xml file.
Another security sandbox feature is that once an SWF is downloaded onto the user’s machine, it has limited access to the local hard drive. “Limited” means that it pretty much has no access whatsoever, except for data being stored in a SharedObject. A SharedObject is a file stored locally on the machine running the SWF that created it. It is available only to the parent SWF, or allowed SWFs within the sandbox boundary. As the developer, you can store client-specific data to the clients’ machines, but you are limited to only 100KB of space per domain. The shared object file itself is stored in a pseudo-random directory path in order to avoid outside tampering. See Chapter 8 for details on how to use shared objects.
Flash Player 9 offers garbage collection that clears the Player’s memory each time the Player is accessed. This will assure the developer that the memory is completely wiped clean so that no application will have access to data stored from prior sessions.
Lastly, Flash Player offers a time-out on procedures that are stuck in recursion loops. For example, if you have a for loop that continues to be executed, eventually the Player will acknowledge this process as potentially harmful, and will prompt the user either to break the execution of the script or allow it to continue. This is particularly useful in ensuring that an SWF cannot execute a denial-of-service attack.
