Flash application security specifications

Author: jianxin [80sec]
EMail: jianxin # 80sec.com
Site: http://www.80sec.com
Date: 2009-07-25
From: http://www.80sec.com/release/flash-security.txt

[Directory]

0 × 00 Preface
0 × 01 secure server flash Security Policy
0 × 02 secure client flash security specifications
0 × 03 flash secure checklist

0 × 00 Preface

Flash, as a third-party browser plug-in, is an extension of browser functions and is already an essential element of web. However, this extension will inevitably lead to insecure factors. Compared with browsers that have been honed by security, flash is definitely a weakness of Client Security (including in the field of mysterious vulnerability mining, this is also the idea). In the same way, flash has a wide range of functions in page display. In some cases, you may even think it is equivalent to javascript, or even more dangerous. The domain security policy implemented by the browser is broken by flash, and the filtering by the client is also broken by flash (as long as you still use flash ). However, flash has already felt this problem and is constantly improving. Some good security mechanisms have also been introduced in the design. Using these security mechanisms properly can prevent your applications from being attacked. 80sec will summarize some flash usage specifications from some practical experience for reference. The specifications will be explained from the two aspects of server application security design and client flash Security usage.

0 × 01 secure server flash Security Policy

Application Security design should adhere to the principle of minimization. In most flash applications, cross-Origin data retrieval is often required due to functional requirements. Domain security is the basic policy for browser security. flash, as an extension of the browser, allows cross-domain data acquisition, which fundamentally breaks the security of the browser. Flash uses the flash file storage domain name as its current domain. Cross-Domain behavior occurs if you need to obtain data from other servers, and the cross-domain behavior will inherit the authentication information in the user's browser, when the limits are not strict, security vulnerabilities will occur, breaking our entire client security model. The only cross-origin restriction policy for flash is the crossdomain. xml file, which limits whether flash can obtain data across domains and where data can be obtained across domains. By strictly controlling this policy file, we can find a balance between application security and functionality.

Typical crossdomain. xml file Policy

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</cross-domain-policy>

The main policy is allow-access-from, which indicates which domains are allowed for cross-origin requests. Early flash allows loading custom policy files from other locations, currently, the latest version of flash checks the crossdomain of the main directory before accepting the custom policy file. xml to determine whether custom policy files are accepted. This option is composed

<site-control permitted-cross-domain-policies="by-content-type"/>

If this option is not added, by default, flash does not load policy files other than the master policy file, that is, it only accepts/crossdomain. xml in the root directory. This is very effective in preventing attacks that use uploaded files to define their own policy files. To enable other policy files under certain conditions, we need to set permitted-cross-domain-policies, when set to by-content-type, only the policy file with the http header text/x-cross-domain-policy is allowed, if it is set to all, all policy files in text/xml format are allowed.

The application follows the minimum principle during design.

1. Separate the file upload and application domain names to prevent the domain operation permission from being directly obtained by uploading flash files.
2. It is strictly prohibited to deploy flash policy files under the domain name directory for applications that do not require flash.
3. For applications with functional requirements, follow the minimization principle to limit the domain name to the minimum range. Applications with security requirements should explicitly allow the domain of cross-origin requests and prohibit direct use of * wildcards, this leads to the spread of cross-origin access permissions.

Like http://sns.80sec.com/crossdomain.xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</cross-domain-policy>

Permission settings are extensive, which may cause bypassing of other security policies (such as bypassing csrf)

4. For applications with high security requirements, restrict the applications that need to be accessed by flash to the specified directory on the premise of limiting the domain name, specify the policy file in flash to this directory to restrict all access permissions to a single directory.

If a function such as login in login.80sec.com needs to be open to all domain names, if you configure the root directory crossdomain. xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

It is not a good policy because it not only opens login, but also opens other services such as chgpassword to users. We need to configure the master policy file.

<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
</cross-domain-policy>

Then customize the policy file to a directory such as/flash/crossdomain. xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Deploy the login application to the/flash/directory. User access is restricted to/flash/and other functions cannot be operated.

0 × 02 secure client flash security specifications

Controlling the flash Security Policy is not all safe, so you can only ensure the security of the server. For some functional reasons, such as the pursuit of a good user experience, in order to allow boring users to share various flash pages, in order to make the pages gorgeous, we often need to embed flash into the page content, so security will be thrown aside (we recommend that you use less dynamic content if you do not need it ). When we introduce a flash on a page, the general method is as follows:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/

flash/swflash.cab#version=8,0,0,0"
name="Main" width="1000" height="600" align="middle" id="Main">
<embed flashvars="site=&sitename=" src=Loading.swf?user=453156346&key=df57546b-c68c-4fd7-9f9c-2d105905f132&v=10950&rand=633927610302991250 width="1000" height="600"
align="middle" quality="high" name="Main" allowscriptaccess="sameDomain" type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>


Because flash is powerful, and its page elements are basically equivalent to dangerous tags such as scripts, for this reason, flash has been considered. When flash is introduced, flash provides control attributes, among them, the AllowScriptAccess attribute and allowNetworking attribute are the most critical to security. AllowScriptAccess controls the communication between flash and html pages. Optional values include:

Always // do not impose any restrictions on the communication with html, that is, the execution of javascript.
SameDomain // only allow flash and html communication from the current domain. This is the default value.
Never // The communication between flash and the page is absolutely prohibited

The default option is sameDomain, which may seem safe in some scenarios. However, we can still see that a program allows you to set this option to always, even sameDomain is not secure in all scenarios. Considering that the upload and display of a program such as a forum are in the same domain, there is no security, we strongly recommend that you set this option to never. If you select sameDomain or always, I also want you to know what you are doing.

AllowNetworking controls the network communication between flash and the outside. Optional values include:

All // allow all network communication, which is also the default value
Internal // flash cannot communicate with browsers, such as navigateToURL, but other APIs can be called.
None // disable any network communication

However, the recently updated flash client seems to be unavailable as long as AllowScriptAccess is set, including navigateToURL. On the official documentation, we only see a simple apology, however, this improves the security of Embedded flash to some extent. But even if we don't jump, we can still do a lot of things. When we embed flash directly into the page without setting allowNetworking, we can do things such as csrf, even worse, this form of csrf supports POST requests. the referer source is the address of the swf file or is empty, and all cookies are sent at the same time, unlike those in images that can only send session cookies, and there are basically no traces. Basically, the second kill of those csrf without token protection has been prevented. The previous kaixinnet made this mistake. We strongly recommend that this option be none, if you do not select this suggestion, you should also know what you are doing.

0 × 03 flash secure checklist

1. Check the crossdomain. xml file in the root directory of your website.

Good child:

http://mail.google.com/crossdomain.xml
http://youa.baidu.com/crossdomain.xml
http://www.adobe.com/crossdomain.xml

Bad child:

http://www.youku.com/crossdomain.xml
http://www.renren.com/crossdomain.xml
http://www.taobao.com/crossdomain.xml

I admit that all the exploitation is inseparable from the scenario. Sometimes it is impossible to modify this crossdomain. xml (this does exist, such as the need for some abnormal functions), you can consider verifying the submitted data when the application obtains data, for example, when x-flash-version is included in the request header, you can determine that the source is flash but not the response, but this is indeed not a beautiful solution.

2. Check your website's flash code.

Is there AllowScriptAccess and allowNetworking? If not, is my application designed to be safe enough to defend against various attacks?

If you want to test the security problem, fly_flash is a good partner to attack the client conveniently (see kaixin.com worm ), if you want to test the policy file that breaks through csrf for the first error, you have to write the source code by yourself. In addition, the biggest enemy of good design is the bad implementation, because it is also between various programs.