LiveCycle® Data Services Developer's Guide

Administering Data Services Applications > Applying Flex Security > Writing secure Flex applications

Writing secure Flex applications

When you code a Flex application, keep the topics in this section in mind to ensure that the application you write is as secure as possible.

Subtopics

MXML tags with security restrictions

Some MXML tags trigger operations that require security settings. Operations that trigger security checks include:

• Referencing a URL that is outside the exact domain of the application that makes a request.
• Referencing an HTTPS URL when the application that makes the request is not served over HTTPS.
• Referencing a resource that is in a different sandbox.

In these cases, access rights must be granted through one of the permission-granting mechanisms such as the allowDomain() method or a crossdomain.xml file.

MXML tags that can trigger security checks include:

• Any class that extends the Channel class.
• RPC-related tags that use channels such as <mx:WebService>, <mx:RemoteObject>, and <mx:HTTPService>.
• Messaging tags such as <mx:Producer> and <mx:Consumer>.
• The <mx:DataService> tag.
• Tags that load SWF files such as <mx:SWFLoader>.

In addition to these tags and their underlying classes, many Flash classes trigger security checks including ExternalInterface, Loader, NetStream, SoundMixer, URLLoader, and URLRequest.

Disabling viewSourceURL

If you enabled the view source feature by setting the value of the viewSourceURL property on the <mx:Application> tag, you must be sure to remove it before you put your application into production.

This functionality applies only to Flex Builder users.

Remove sensitive information from SWF files

Flash applications share many of the same concerns and issues as web pages when it comes to protecting the security of data. Because the SWF file format is an open format, you can extract data and algorithms contained within a SWF file. This is similar to how HTML and JavaScript code can be easily viewed by users. However, SWF files make viewing the code more difficult. A SWF file is compiled and is not human-readable like HTML or JavaScript.

But security is not obtained through obscurity. A number of third-party tools can extract data from compiled SWF files. As a result, do not consider that any data, variables, or ActionScript code compiled into a Flash application are secure. You can use a number of techniques to secure sensitive information and still make it available for use in your SWF files.

To help ensure a secure environment, use the following general guidelines:

• Do not include sensitive information, such as user names, passwords, or SQL statements in SWF files.
• Do not use client-side username and password checks for authentication.
• Remove debug code, unused code, and comments from code before compiling to minimize the amount of information about your application that is available to someone with a decompiler or a debugger version of Flash Player.
• If your SWF file needs access to sensitive information, load the information into the SWF file from the server at run time. The data will not be part of the compiled SWF file and thus cannot be extracted by decompiling the SWF file. Use a secure transfer mechanism, such as SSL, when you load the data.
• Implement sensitive algorithms on the server instead of in ActionScript.
• Use SSL whenever possible.
• Only deploy your web applications from a trusted server. Otherwise, the server-side aspect of your application could be compromised.

Input validation

Input validation means ensuring that input is what it says it is or is what it is supposed to be. If your application is expecting name and address information, but it gets SQL commands, have a validation mechanism in your application that checks for and filters out SQL-specific characters and strings before passing the data to the execute method.

In many cases, you want users to provide input in TextInput, TextArea, and other controls that accept user input. If you use the input from these controls in operations inside the application, make sure that the input is free of possible malicious characters or code.

One approach to enforcing input validation is to use the Flex validator classes by using the <mx:Validator> tag or the tag for the appropriate validator type. Validators ensure that the input conforms to a predetermined pattern. For example, the NumberValidator class ensures that a string represents a valid number. This validator can ensure that the input falls within a given range (specified by the minValue and maxValue properties), is an integer (specified by the domain property), is non-negative (specified by the allowNegative property), and does not exceed the specified precision.

In typical client-server environments, data validation occurs on the server after data is submitted to it from the client. One advantage of using Flex validators is that they execute on the client, which lets you validate input data before transmitting it to the server. By using Flex validators, you eliminate the need to transmit data to and receive error messages back from the server, which improves the overall responsiveness of your application.

You can also write your own ActionScript filters that remove potentially harmful code from input. Common approaches include stripping out dollar sign ($), quotation mark ("), semi-colon (;) and apostrophe (') characters because they have special meaning in most programming languages. Because Flex also renders HTML in some controls, also filter out characters that can be used to inject script into HTML, such as the left and right angle brackets ("<" and ">"), by converting these characters to their HTML entities "&lt;" and "&gt;". Also filter out the left and right parentheses ("("and ")") by translating them to "&#40;" and "&#41;", and the pound sign ("#") and ampersand ("&") by translating them to "&#35" (#) and "&#38" (&).

Another approach to enforcing input validation is to use strongly-typed, parameterized queries in your SQL code. This way, if someone tries to inject malicious SQL code into text that is used in a query, the SQL server will reject the query.

For more information on potentially harmful characters and conversion processes, see http://www.cert.org/tech_tips/malicious_code_mitigation.html.

For more information about validators, see Flex 2 Developer's Guide.

ActionScript

Flex provides the following ways to make your use of ActionScript more secure.

Subtopics

Handling errors

The SecurityError exception is thrown when some type of security violation takes place. Security errors include:

• An unauthorized property access or method call was made across a security sandbox boundary.
• An attempt was made to access a URL not permitted by the security sandbox.
• A socket connection was attempted to an unauthorized port number, for example, a port below 1024, without a policy file present.
• An attempt was made to access the user's camera or microphone, and the request to access the device was denied by the user.

Flash Player dispatches SecurityErrorEvent objects to report the occurrence of a security error. Security error events are the final events dispatched for any target object. This means that any other events, including generic error events, are not dispatched for a target object that experiences a security error.

Your event listener can access the SecurityErrorEvent object's text property to determine what operation was attempted and any URLs that were involved, as the following example shows:

<?xml version="1.0"?>
<!-- security/SecurityErrorExample.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp()">
    <mx:Script><![CDATA[
        import flash.net.URLLoader;
        import flash.net.URLRequest;
        import flash.events.SecurityErrorEvent;
        import mx.controls.Alert;

        private var loader:URLLoader = new URLLoader();

        private function initApp():void {
            loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
        }
        
        private function triggerSecurityError():void {      
            // This URL is purposefully broken so that it will trigger a
            // security error.
            var request:URLRequest = new URLRequest("http://www.[yourDomain].com");
            
            // Triggers a security error.
            loader.load(request);
        }

        private function securityErrorHandler(event:SecurityErrorEvent):void {
            Alert.show("A security error occurred! Check trace logs for details.");         
            trace("securityErrorHandler: " + event.text);
        }
    ]]></mx:Script>

    <mx:Button id="b1" label="Click Me To Trigger Security Error" click="triggerSecurityError()"/>

</mx:Application>

If no event listeners are present, the debugger version of Flash Player automatically displays an error message that contains the contents of the text property.

In general, try to wrap methods that might trigger a security error in a try/catch block. This prevents users from seeing information about destinations or other properties that you might not want to be visible.

Suppressing debug output

Flash Player writes debug output from a trace() method or the Logging API to a log file on the client. Any client can be running the debugger version of Flash Player. As a result, remove calls to the trace() method and Logging API calls that produce debugging output so that clients cannot view your logged information.

If you use the Logging API in your custom components and classes, set the value of the LogEventLevel to NONE before compilation, as the following example shows:

myTraceTarget.level = LogEventLevel.NONE;

For more information about the Logging API, see Using the Logging API.

Using host-based authentication

IP addresses and HTTP headers are sometimes used to perform host-based authentication. For example, you might check the Referer header or the client IP address to ensure that a request comes from a trusted source.

However, request headers such as Referer can be spoofed easily. This means that clients can pretend to be something they are not by settings headers or faking IP addresses. The solution to the problem of client spoofing is to not use HTTP header data as an authentication mechanism.

Using passwords

Using passwords in your Flex application is a common way to protect resources from unauthorized access. Test the validity of the password on the server rather than the client, because the client has access to all the logic in the local SWF file.

Never store passwords locally. For example, do not store username and password combinations in local SharedObjects. These are stored in plain-text and unencrypted, just as cookie files are. Anyone with access to the user's computer can access the information inside a SharedObject.

To ensure that passwords are transmitted from the client to the server safely, enforce the use of SSL or some other secure transport-level protocol.

When you ask for a password in a TextArea or TextInput control, set the displayAsPassword property to true. This displays the password as asterisks as it is typed.

Storing persistent data with the SharedObject class

Flash Player supports persistent shared objects through the SharedObject class. The SharedObject class stores data on users' computers. This data is usually local, meaning that it was obtained with the SharedObject.getLocal() method. You can also create persistent remote data with the SharedObject class; this requires Flash Media Server (formerly Flash Communication Server).

Each remote sandbox has an associated store of persistent SharedObject directory on the client. For example, when any SWF from domain1.com reads or writes data with the SharedObject class, Flash Player reads or writes that object in the domain1.com object store. Likewise for a SWF from domain2.com, Flash Player uses the domain2.com store. To avoid name collisions, the directory path defaults to the full path in the URL of the creating SWF file. This process can be shortened by using the localPath parameter of the SharedObject.getLocal() method, which allows other SWF files from the same domain to access a shared object after it is created.

Every domain has a maximum amount of data that a SharedObject class can save in the object store. This is an allocation of the user's disk space in which applications from that domain can store persistent data. Users can change the quota for a domain at any time by choosing Settings from the Flash Player context menu. When an application tries to store data with a SharedObject class that causes Flash Player to exceed its domain's quota, a dialog box appears, asking the user whether to increase the domain quota.

LiveCycle Data Services ES 2.5

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/livecycle/es/sdkHelp/programmer/lcds/security2_10.html

Add Comment