FLASH application security Attack and Defense

Adobe Flash technology has become increasingly popular. Now it is used not only to create animations and advertisements, but also to develop complex Internet applications. Flash applications (SWF files) not only can be distributed through the Web protocol, but also can read local or remote files, establish network connections, and communicate with other SWF files. Through this article, you will learn about specific flash attack methods, useful Flash Security Review techniques, and security-related development/configuration technologies.

I. XSS threats

Anyone engaged in Web application development or testing knows that Web applications have a common security vulnerability, known as cross-site scripting (XSS ). Generally, if an application accepts malicious code from untrusted sources and directly returns it to unprotected users without sanitizing the data, XSS occurs. Although flash applications are not immune to XSS and other types of security threats, however, Web administrators and FLASH application developers can take appropriate security measures to improve the security of such emerging technologies.

Generally, during cross-site scripting attacks, attackers need to inject malicious script code (such as JavaScript or VBScript Code) into web applications, this is usually done by deceiving users to click a link or access an evil web page. Then, the Web application will display and execute the injected code in the context of the victim's web session. This attack usually results in user account theft, but does not cause command execution, unless the browser security vulnerability is also exploited. Because SWF programs can be embedded into websites and have full access to HTML dom (Document Object Model), they can be used to launch XSS attacks. Imagine a Free Email web service that displays third-party Flash ads: a malicious Advertiser can create a malicious swf application to hijack your email account to send spam. By default, Flash Player has full access permissions to the DOM in the same domain.

The following describes the basic process of XSS attacks against SWF applications. Step 1: attackers must first try to inject code into the application so that the code can be re-displayed to other users. Adobe provides programmers with a variety of user interface components, such as a combo box, radio buttons, and text fields. Their usage is very similar to that of HTML form objects. In addition, there are many ways for SwF applications to accept parameters from external input.

We can use the <Object> and <embed> labels to embed the flashvar attribute into an HTML document.

Figure 1

In addition, you can pass data directly through the URL:

Figure 2

In addition, the class loadvars can be used to load external data.

Figure 3

Flashvars is automatically imported to the variable space of the flash application for ActionScript 2. However, additional code is required to load external parameters in ActionScript 3. A common error is that, after receiving data from flashvars or URL parameters, they are directly passed to those functions that communicate directly with the browser without proper input verification. The geturl function in ActionScript 2 and the navigatetoURL function in ActionScript 3 can load the specified URL to a browser window. Consider the following ActionScript code:

Figure 4

This Code uses a variable from an external source to call the function geturl, which redirects the user to the specified URL. For example, an attacker may create the following request:

Figure 5

After the request is sent, a javascript warning box is displayed and the site cookie content is displayed. Cookies are often used to store sensitive account data, such as session identifiers. Dom is a standard object model used to represent HTML in a tree structure. Dom can be used by JavaScript code to dynamically explore or modify HTML pages. Consider the following JavaScript code, which will change the source attribute of the first image on this HTML page. After the Attribute source is modified, the image displayed on the page will also change accordingly.

Figure 6

One common method for attackers is to insert a new image by modifying the HTML Dom, and direct the Attribute source of the image to a file on the server controlled by the attacker, the cookie content is also used as a parameter. In this way, attackers can obtain cookie data as long as they monitor the logs of their computers. If the session ID is contained in the session, the attacker can fully control the user's account until the session expires. Another ActionScript function can be used to launch XSS attacks. It is fscommand. SWF files can communicate with Flash Player or programs hosting Flash Player through this fscommand function. Generally, flash player will reside in a Web browser, but it can also be located in other programs that can host ActiveX controls. The fscommand function consists of one command and one parameter. The following fscommand function sends a changetext command. The parameters of this command are specified by flashvar.

Figure 7

The javascript code in Listing 1 can therefore be stored in the HTML document that processes the commands sent by the SWF application. It only gets parameters and then modifies the HTML elements specified by text. Developers should pay attention to the types of input data received from users for the fscommand function, and how parameters are used in the HTML document.

Listing 1. Code for receiving fscommand

Figure 8

List 2. Simple Password check code

Figure 9

The preceding sample code provides a convenient way for attackers to directly inject HTML or script code into the Dom. For example, the following request will include and execute a Javascript file stored on the remote host.

Figure 10

Ii. html Components

Adobe supports a subset of standard HTML tags. We can use the text field component or textarea component in corner 2.0 to put these supported HTML tags into flash movie clips. If strict verification is not performed on user input used to construct HTML, both components may be abused. Verify the image and anchor tags with extra caution because they are especially vulnerable to security vulnerabilities. In flash, the label can not only embed external image files in SWF files and movie clips, but also embed SWF files and movie clips to launch various attacks. The following Code assigns data from external sources to the HTML text component:

Figure 11

An attempt to embed Javascript into an image will fail, because Flash Player seems to verify whether the image is in JPEG, GIF, or PNG format.

Figure 12

However, the following code proves that Flash Player verification is too pediatric. Just check that the specified sourcew.jpg string ends with a. jpg string. Therefore, you only need to add a line comment similar to the C language. You do not need to change the function of the script code to cheat Flash Player to execute the script in the label. Once the browser loads the SWF file, the Javascript will be executed without manual intervention and a pop-up window will appear.

Figure 13

With this method, we can easily inject Javascript or VBScript into the textarea component. The following request does not provide such verification for the anchor tag, but such XSS attacks require manual intervention. You must click the connection to run the code.

Figure 14

As mentioned above, the label can load not only the actual image file, but also the SWF file. This may cause a malicious swf file to be loaded into a trusted application. When loading other SWF files, use a box cover to restrict the display area of the sub-SWF file. If no frame cover is set for the original SWF, the sub-SWF file may overwrite the entire playing area. This can be used to cheat trusted applications. However, if the injected SWF is from an external domain, the flash security policy is still effective for it.

Iii. Function protocols of ActionScript

The above example uses JavaScript to demonstrate common XSS attacks, but there is a protocol specifically used for flash, that is, asfunction, which can cause a connection to call an ActionScript function. For example, when you click an anchor point in the textarea component, the following code calls the local function Foo with two parameters.

Figure 15

Obviously, this ability to directly call The ActionScript function from the HTML component has a great security risk. Consider a simple FLASH application shown in Listing 2, which performs identity verification by receiving the user name and password. When a user enters an incorrect password, the user name is displayed as an HTML-based textarea group. Assume that a user name is entered as follows and a password is guessed at will.

Figure 16

The application will notify this user that the provided user name/password is invalid, and the user injection anchor is displayed as part of the HTML output. When you click this link, the setpassword function is called to set the password to ABC. The preceding example shows that it is very dangerous to allow users to execute arbitrary ActionScript functions to manipulate application data. If a flash application has a persistent XSS security vulnerability, this may cause a bad user to allow other users to execute arbitrary flash letters in a trusted sandbox. Trusted SWF files can even read local files and send messages to any server. ActionScript contains a variety of function libraries. Therefore, attackers can use these library functions to connect to the Internet and communicate with each other through more advanced attack types, so that they can access the local file system.

4. uninitialized variables

PHP programmers may have heard of a controversial feature called register globals, which allows the post and get requests to inject the variables in the request into the variable space of a script. Of course, this feature is not often used, and some programmers do not even know that it is stored. Due to the high criticism, this feature will be removed from the new Php 6. Theoretically, register globals may also be used to write completely secure programs. However, a large number of vulnerabilities found in web applications are due to improper use of this feature.

It also has a similar feature, but it was canceled in version 3, but it is still worth our attention because it is still widely used in the Flash community. Any uninitialized variables can be initialized as flashvar. When the programmer forgets to assign an initial value to the key variable or specifies the variable as undefined, it is likely to cause future problems. Consider the code in listing 3, which determines whether users are allowed to view confidential information.

Listing 3. code example dependent on uninitialized variables

Figure 17

The programmer depends on the fact that if the variable userloggedin is not initialized, It will be set to undefined. The value of undefined is treated as false in the Condition Clause. It is easy to bypass the code in ActionScript 2 because the variable userloggedin is not initialized. Set userloggedin to true in a GET request or as an object parameter in HTML, as shown below:

Figure 18

In ActionScript 3, flashvars can only be accessed through the parameter attribute of the loaderinfo class, which makes the attack against uninitialized data no longer feasible. However, developers should still carefully check all parameters passed to SWF.

5. SWF Communication

Similar to the cookie mechanism of the browser, the local shared object (LSOS) provides a small amount of persistent storage space for SwF applications. LSO may be restricted by specific domains, local paths, or HTTPS connections. The code in Listing 4 generates a shared object, which can be stored in/a/B or its sub-directories (such as A/B/C) other SWF programs under. The function flush will force this object to be written to this file.

Listing 4. Example code of mongodobject

Figure 19

If you want to store confidential information in a local shared object, you can set the flag secure to true so that the SWF can be accessed only through HTTPS. Regardless of how they are transmitted, LSOS is stored in the client's machine in plain text. Because ActionScript does not provide encryption classes, if you want to protect important information stored in LSO, you have to use a third-party encryption library.

To enable direct communication between SWF applications running on the same client machine, actionscript provides the localconnection class. At this time, a SwF application must act as the receiver and the other as the sender. These SWF applications do not have to run in the same browser, but by default, only SWF programs in the same domain can communicate with each other. In the debugging phase, developers often use the allowdomain function to relax this default security restriction. The code in listing 5 allows localconnection to receive data.

Listing 5. Code for accepting localconnection

Figure 20

If the product code leaves allowdomain ('*'), it will be very dangerous because it allows any SWF program from any domain to access the internal functions of your application. The best way to use wildcard is to allow only SWF communication between the same domain or subdomain. For example, allowdomain ("* .test.com") will allow communication between www.test.com and mail.test.com. To send data, use the localconnection function, as shown in Listing 6. If function connect is not used, the sender can directly call the function send by using the desired function name and parameter.

Listing 6. Code for sending localconnection

Figure 21

6. correct input verification

A common input verification method is to check whether a piece of data matches a regular expression. A regular expression is used to describe a character pattern. In version 3, actionscript provides local support for regular expressions and uses the emcascript language specification to implement regular expressions. Traditional developers who still use ActionScript 2 cannot use regular expressions or third-party libraries such as as2lib to verify data. Consider the following vulnerable code:

Figure 22

Do not blindly trust emails submitted by users, but use regular expressions for dual checks to reject malicious users. The code in listing 7 provides a function example to test whether an email address is valid using a regular expression.

Listing 7. Verify the email rule expression

Figure 23

If your application must be migrated to ActionScript 3.0, you can perform input verification without using a regular expression, although this solution is not elegant and does not comply with RFC standards. When you do not need a regular expression to verify the input, you generally need to call many standard string functions, as shown in listing 8.

Listing 8. Email verification without rule expressions

Figure 24

If you must use the data entered by the user for the geturl function or HTML text component, you can use a regular expression to define the data that is acceptable, and only accept HTTP or HTTPS protocol processors for valid links. Do not rely on escape functions for input verification. According to the Flash help documentation, the escape function converts parameters into a string and encodes them in URL encoding format, the non-alphanumeric characters are replaced by the % hexadecimal sequence. Consider the following code. It does not use the escape function correctly for input verification.

Figure 25

The escape function cannot prevent malicious users from intruding into JavaScript Functions and executing arbitrary script code. For example, see the following request:

Figure 26

7. Securely publish content

Not only should Flash developers spend time verifying input, but Web administrators should also set security measures to prevent untrusted SWF files from accessing browsers and/or networks. You can use the <Object> <embed> label to embed the SWF application into an HTML page as an object. You can specify three optional parameters in the <embed> or <Object> label that affects the security policy. The allowScriptAccess parameter controls whether the SWF file can access the HTML container. The allownetworking parameter controls the capability of SwF to use the network API of ActionScript. Finally, the allowfullscreen parameter determines whether the FLASH application is allowed to control the entire screen.

The allowScriptAccess parameter has three possible values:

◆ Always: Allows SWF to communicate with HTML pages, regardless of the domain name of the HTML page. This option can be used only when the SWF is fully trusted. It is the default action of Flash Player 7 and earlier versions.

◆ Samedomain: The SwF application can modify the underlying HTML page only when the two are in the same domain. The Flash application in the domain www.a.com cannot modify the HTML page in www. B .com. This is the default action of Flash Player 8 and later versions.

◆ Never: Never allow communication between HTML pages and SwF applications.

The allownetworking parameter also has three possible values:

◆ All: SwF applications are allowed to use network APIs to establish unlimited network connections.

◆ Internal: SwF applications cannot call browser navigation or interactive APIs, but can call other networks.

◆ None: Prohibit SWF applications from using any network APIs.

The allowfullscreen parameter has only two possible values:

◆ True: the SWF application is allowed to occupy the entire screen. This option may be maliciously used to trick attacks.

◆ False: fullscreen mode is not allowed.

Many popular forums allow their administrators to create their own bbcode so that users can format discussion posts or include additional content. Many administrators have added bbcodes that support SWF. Consider replacing flash bbcode with the insecure HTML code below.

Figure 27

In a hostile SWF application setting that you cannot trust any post, you must explicitly set allownetworking, allowScriptAccess, and allowfullscreen in the <embed> label, to prevent malicious applications from calling unauthorized networks or scripts. You should not rely on the default Flash Player Security Settings, but assume that some users cannot or are unwilling to update the software. The HTML code in listing 9 provides security settings.

Listing 9. Add appropriate security settings for html object tags

Figure 28

VIII. Security Analysis Tools

Currently, few tools are available for security auditing of flash applications. Stefano di Paola has developed a sophisticated tool called swfintruder to detect cross-site scripting and cross-site flash vulnerabilities. This tool provides a set of predefined attack methods that can be customized and perform XSS testing in a semi-automated manner. This tool runs on a Web server and can be accessed through a browser. It displays all undefined variables and all instantiated variables in the SWF application.

You can select a parameter to test and execute various attacks, and provide the XSS scan output results. One of the major limitations of swfintruder is that it can only analyze flash applications created earlier than version 8 or later in ActionScript 1 or 2. When auditing flash applications or components with closed source code, the anti-compiler is particularly important. The anti-compiler provides an inverse process for compiling a program because it converts low-level computer code into high-level abstract code. The Flash anti-compiler accepts the bytecode of the SWF application and then generates the corresponding ActionScript code, which is easier for humans to read. To expose security defects, it is easier to use static analysis tools to analyze generated ActionScript code. One example of a free anti-compiler is flare, which extracts all the ActionScript files from a SwF application. However, like swfintruder, flare does not support ActionScript. However, commercial products can generate FLA files from actionscript1/2 or actionscript3, provided that they have to pay for them.

IX. Conclusion

When developing web-based rich applications, many FLASH application developers did not realize that they were under various security threats from malicious users. Although the security community is no stranger to XSS, initial variable attacks, and other input verification vulnerabilities, flash provides a new type of attack, especially the unprotected and strictly tested flash programs. However, as long as programmers, testers, and Web administrators work closely together, after appropriate training and strict checks on the input end, this effectively reduces the threat caused by the cross-site scripting vulnerability in flash applications.