Flash Player Article

Creating more secure SWF web applications

Potential threats to SWF files

This section provides a brief overview of the different high-level threats that you should consider when developing SWF applications. Although there are more granular threats that could be defined within a specific context for any SWF file, this overview covers the high-level threats common to most SWF deployments. Throughout the rest of the document, "Related Threats" entries will map these threats to specific Flash Player APIs and concepts. Each section will then describe the mitigation strategies that apply to the identified threats.

Cross-domain privilege escalation

Cross-domain loading may allow a remote SWF to have unintended access to the loader's domain and data. If the loading SWF imports the remote SWF file into its security domain, then the loaded SWF could gain access to the parent SWF's data and relay that data back to an attacker. In addition, depending on settings within the web page, the loaded SWF could inject script into the loaded SWF file's web page. These attacks could occur whenever the end-user can gain control over movies that are loaded by a parent SWF file. Cross-domain privilege escalation is a high-level threat that can expose a SWF to more specific threats such as spoofing, script injection into the browser, malicious data injection, DNS rebinding and insufficient authorization restrictions. This threat exists whenever content from multiple remote sources is loaded and processed under a single security domain.

Spoofing

A remotely loaded SWF may try to render its controls over the top of the loading SWF in an attempt to perform a spoofing attack. By overlaying the parent SWF, the malicious SWF can hijack control from the loading SWF file. For instance, if developers do not set masks on Loaders to limit the remote SWF file to a particular area of the Stage then an attacker could perform a spoofing attack.

Malicious data injection

Injecting malicious data into applications is how most vulnerabilities are found by attackers. A Flash application may receive malicious data injection from several types of interfaces. For example, it is common for FlashVars to be set via the Object tag within the HTML. However, developers sometimes forget that these variables can be set via the URL where it is trivial for an attacker to alter the values. For example, if the FlashVar value is a URL that points to remote content such as another SWF, then the attacker could alter the URL to point to a malicious SWF instead. In ActionScript 2.0, any un-initialized value can automatically be set via the URL as a FlashVar. In ActionScript 3.0, you must explicitly request the value of each FlashVar variable and manually assign that value to an internal variable.

Other examples where malicious data inject can include any time a SWF loads remote data—such as when a SWF file obtains data from a LocalConnection, the SWF file remotely loads variables from a server, or the SWF file imports data from another SWF file. A SWF file will be exposed to this threat if you do not perform data validation on remotely obtained data.

Script injection into the browser

In some instances, website owners may host third-party SWF files on their site. However, the website owners may not want to grant the third-party SWF files read and write access to their HTML or JavaScript code. Incorrectly setting permissions could allow an attacker to rewrite the entire page or redirect the users from the trusted site to a phishing site. This threat exists for web administrators that host third-party SWFs as well as for SWF files that accept URLs via FlashVars.

The most common vulnerability to consider is an attacker injecting data in order to conduct a cross-site scripting (XSS) attack. Assume that the target SWF takes a URL value from a FlashVar and sends that information to a navigateToURL or a getURL command. An attacker who notices this behavior may try to replace the original URL value of the FlashVar with a "javascript:" URL. JavaScript URLs sent to the browser through getURL or navigateToURL methods will execute within the context of the domain hosting the SWF. The javascript: URL can contain any set of JavaScript commands including commands to steal the cookies from the domain and forward them to a third-party site. A cross-site scripting attack could also occur if a malicious remote SWF is imported into the trusted SWF and then the remote SWF calls a javascript: URL.

Insufficient authorization restrictions

Excessive cross-domain permissions may allow relay attacks, spoofing, data theft or other attacks. For example, a malicious SWF file may try to exploit overly permissive cross-domain policy file permissions to steal protected data from a remote website. Another example might be an untrusted SWF that is able to send malicious data to another domain via a LocalConnection. Weak domain restrictions can occur when wildcards are misused in allowDomain methods or cross-domain files.

Developers often consider a cross-domain threat to be domain www.a.com gaining unauthorized access to www.b.com. However, developers must also consider whether their SWF files will be hosted within a shared environment. This can include situations where a developer's content is hosted under http://www.host.com/~user1 and the content under http://www.host.com/~user2 is not explicitly trusted by the developer. This can also occur in advertising situations where ads from multiple sources are hosted on the same domain. There are situations where Flash Player takes directory and file paths into account in determining authorization such as with LocalConnections. There are other situations where only the hosting domain is considered such as allowDomain() settings. Developers need to take shared hosting situations into account when designing mitigations to this threat.

Unauthorized access to data in transit

An attacker may try to read or alter data sent over unencrypted channels such as RTMP and HTTP. If the SWF file is performing critical functions (such as collecting credit card data within a shopping cart), then the attacker could potentially view that data. An attacker may also try to manipulate traffic and attempt to replace the trusted SWF files with malicious SWF files before they reach the end-user. Vulnerabilities for this threat include when secure communication channels such as HTTPS or RTMPS are not used to protect sensitive data.

Insecure communications can also occur when SWF files loaded over HTTP can access the data of SWF files loaded over HTTPS. By default, an HTTP-loaded SWF file may not access data from SWF files loaded over HTTPS. However, if data is shared between an HTTP SWF and an HTTPS SWF then the data may be transmitted over an insecure channel. This can occur if an allowInsecureDomain method is misused or when the secure flag is set to false in a crossdomain.xml file.

Unauthorized local data access

An attacker may attempt to steal sensitive local data from SWF files and local shared objects. SWF files can be decompiled and local shared objects can be read by third-party applications. An attacker may also try to obtain the information dynamically through cross-scripting. This threat includes vulnerabilities such as when developers store sensitive data within SWF applications and shared objects.

Cross-site request forgery

Cross-site request forgery (XSRF) is where an attacker exploits a user who has visited their website by initiating an unauthorized request to another site to which the user is authenticated. If the target website utilizes atomic (single submit) actions for updates to user information, then the attacker can initiate a change to the user's account on that site by forcing the browser to make a request to the site. The attacker does not need the user's cookies to perform the attack since the browser will automatically append them to the request. The attacker is usually unable to directly see the results of their update but the change will be made nonetheless. Due to the current design of the web, protections against these attacks are currently being implemented by the websites themselves and not by the browser or its clients. Since Flash Player utilizes the browser to make web requests, Flash Player can be used as a tool in performing cross-site request forgery attacks.

DNS rebinding

Web browsers and Flash Player use domain names for establishing authorization to data as part of the same-origin policy. An attacker can try to bypass the same-origin policy by tricking the web browser to continually update the IP address it has recorded for a particular domain name. For this attack to work, the attacker must have a DNS server under their control and a malicious website. Through varying techniques, the attacker can update the IP address for their domain name within their DNS server and then force the web browser to retrieve the updated information. Therefore, the attacker can make their domain name first point to the IP of their public website, then point to an IP of a trusted server on the victim's internal network and then point back to their public website.

For all of these requests, only the IP address is changing and the domain name used to establish the requests remains the same. Since the domain name remains the same for all requests, the web browser considers the connection to the trusted internal server and the connection to the attacker's public web server to be equivalent with regards to security. This allows the attacker to steal information from the internal web server and send that data back to the public website. For many types of requests, Flash Player relies on the hosting web browser to establish HTTP connections. Therefore any DNS rebinding attack that is applied to the web browser will also affect Flash Player. This attack may also be applied to Flash socket connections.

Page 2 of 13

Previous Page

Next Page