Accessibility

Table of Contents

Creating more secure SWF web applications

Encrypting data

Several strategies are available to encrypt data in SWF web applications. These strategies are discussed briefly below.

Hashing algorithms

Related threats: Unauthorized access to data in transit, unauthorized access to local data

To learn more about working with the hashing algorithms discussed in this section, see the as3corelib project page on Google Code, the Alchemy ActionScript 3 Crypto Wrapper library on Adobe Labs, and the Flex 3 SDKs on Adobe Open Source.

Hashing is a method for performing non-reversible encryption that transforms the original text into a unique string, or hash. Since the hash is non-reversible, there is no method for converting the hash back into the original text. These algorithms are useful for handling processes such as password authentication and storage. In many applications, passwords are processed through a hashing algorithm and then the resulting hash is stored on disk. When an end-user authenticates to an application, a hash of the supplied password is created to determine if it results in the same unique string as the stored password hash. If the two hashes match, then the user is granted access. This methodology allows administrators to store passwords in a non-plaintext format without the risk of the password being decrypted and stolen.

As one example, as3corelib started as an Adobe Labs project and is now part of the Google Code project. It provides several utilities for JSON, web services, and cryptography. The cryptography library includes methods for supporting SHA256, SHA224, SHA1, MD5, and the WSSEUsernameToken. Adobe recommends using SHA256 in place of SHA1 or MD5 whenever possible—due to known cryptographic attacks against the hashing algorithms. Corelib requires libraries from the free Flex 3 SDK to perform the base-64 encoding:

// Import the SHA256 library from CoreLib
import com.adobe.crypto.SHA256;
// Initialize the string that needs to be hashed
var myString:String = "HashMe";
// Create a hex representation of the SHA256 Hash
var hexHash:String = SHA256.hash (myString);
// Create a base64 representation of the SHA256 Hash
var base64Hash:String = SHA256.hashToBase64(myString);

In addition to as3corelib, the Flex 3 SDK includes a SHA256 implementation that is available to Flex developers.

Lastly, a project from Adobe Labs called Alchemy allows developers to port C applications to ActionScript. As an example of this functionality, a port of the OpenSSL library was created and is available from the Alchemy Libraries page. This port includes support for SHA, SHA2, and MD5, as well as a demo app demonstrating how to leverage them.

Symmetric and asymmetric ciphers

Related threats: Unauthorized access to data in transit, unauthorized access to local data

To get more details about working with the AS3Crypto Framework 1.3, see the as3crypto library page on Google Code. To get more details about working with the Adobe Alchemy ActionScript 3 Crypto Wrapper library, see the Alchemy Libraries page on Adobe Labs.

Symmetric and asymmetric ciphers are useful when you want to create a reversible encryption of data. Several implementations of symmetric and asymmetric ciphers written in ActionScript can be found on the web. These are useful to leverage but developers have to be aware that SWF files can be decompiled. Therefore the secret and private keys for these tools cannot be stored within the SWF file itself. At a minimum, symmetric secret keys and asymmetric private keys would have to be downloaded over a secure Internet protocol or generated by the SWF on the end-users machine to prevent exposure.

Threats to keys within SWF files

There are several threats with using symmetric and asymmetric secret keys within a SWF file. If the symmetric or secret key is stored in a shared object, then you would have to keep in mind that shared objects are non encrypted and can therefore be read by the user or by malicious software on the user's machine. Careful consideration should also be given to before making any changes to the default localPath setting since this will expand the number of SWF files that can read the data within the shared object. Setting the secure flag on the shared object to true can help limit the access to the shared object to securely loaded SWF files. A SWF file loaded over HTTP would be subject to a man-in-the-middle attack and, if an attacker successfully replaces the SWF file in transit, then the malicious SWF file could steal the key out of the Shared Object. External SWF files hosted on the same domain, that are import loaded into the encrypting SWF and any external SWF files that are granted permissions through the Security.allowDomain() settings, could also have cross-scripting permissions to obtain the key from the SWF file.

If you decide to use an asymmetric cipher, it is possible to safely store the public key within the SWF file. The public key can be used for encrypting data prior to sending it to a server application that has the corresponding private key. This approach allows one-way communication of encrypted data to the server and can also be used to verify digitally signed data sent from the server to the SWF file. One example where this would be useful is in situations where it necessary to collect sensitive data, such as a password, and send it to the server. Since the SWF file would contain the public key and the public key is only used for encryption, it would not matter if someone decompiled the SWF file to steal the key. The attacker could send malicious encrypted data to the server but the server programmer should perform data validation regardless of whether encryption was used.

There are performance considerations with using cryptography, so perform thorough testing if the cryptography will be used extensively. For instance, RSA encryption tends to be faster than RSA decryption. In many situations, it may be easier and safer to leverage the HTTPS protocol for sending encrypted data instead of performing the encryption within ActionScript code.

Support for AES and RSA can be found in several frameworks, including the Alchemy ActionScript 3 Crypto Wrapper library on Adobe Labs and the open-source AS3Crypto Framework.

The following sample code demonstrates using the RSA encryption algorithm to encrypt data using the open source AS3Crypto Framework library. The AS3Crypto Framework provides support for RSA, AES, 3DES, Blowfish, SHA, MD5, HMAC, and several other cryptographic solutions. This code is solely intended to demonstrate that public key crypto is possible with an open source solution.

Note: Adobe did not author the AS3Crypto library and is not responsible for its maintenance or development. Developers should choose a library that they trust and is appropriate for their needs.

import com.hurlant.crypto.rsa.RSAKey;
import flash.utils.ByteArray;
import com.hurlant.util.Hex;
import com.hurlant.util.der.PEM;
// The public key containing no spaces or carriage returns
// An openssl public key generated by:
//   openssl rsa -pubout -in private_key.pem -out public_key.pem
// should work for baseline testing
var myPEMPublicKeyString = "-----BEGIN PUBLIC KEY-----{BASE64 DATA with no spaces or return characters}-----END PUBLIC KEY-----";
// Put data to be encrypted into a byte array
var data:ByteArray = Hex.toArray(Hex.fromString("MyInputString"));
// Destination ByteArray that will contain the encrypted data
var encryptedResult:ByteArray = new ByteArray;
// Set up the RSAKey and encrypt the data
var rsa:RSAKey = PEM. readRSAPublicKey(myPEMPublicKeyString);
rsa.encrypt(data, encryptedResult, data.length);
// Convert the encrypted data into a hex encoded string for transport
// The other side of the connection can convert the hex back into
// binary before decrypting
hexEncryptedResult = Hex.fromArray(encryptedResult);

Where to go from here

Deploying more secure SWF applications to end-users requires a coordinated effort from Adobe, Flash application developers, and website administrators. With each new release of Flash Player, Adobe strives to introduce a stronger platform with more robust security controls and tools for creating secure applications. By leveraging those tools, compiling for recent versions, performing data validation, and leveraging available SDKs, developers can produce more secure applications that run in Flash Player.

Website administrators can deploy these SWF files on their site by leveraging object tag parameters, appropriately deploying cross-domain policy files on their site and by working with developers on an agreed upon plan for access and deployment. By following these techniques, Flash Player applications can provide a rich Internet experience and a more secure environment for end-users.

Be sure to check out the following additional resources for further information on Flash Player security:

Adobe resources

Other resources