CSRF with Flash

Author: lake2 [80sec]
EMail: lake2 # 80sec.com
Site: http://www.80sec.com
Date: 2008-10-04
From: http://www.80sec.com/release/csrf-with-flash.txt
-----------

[Directory]

0 × 00 is purely nonsense
0 × 01 use flash to initiate CSRF attacks
0 × 02 surpassing JavaScript Hijacking
0 × 03 cross-domain flash Policy
0 × 04 Cross-Domain Policy bypass flash
0 × 05 flash restrictions
0 × 06 Windows Media Player risks
0 × 07 Preventive Measures
0 × 08 postscript

-----------

0 × 00 is purely nonsense

The world is changing too fast, and you will lag behind when you leave nothing to worry. Now it seems that CSRF is still quite common. For a positive significance, This article focuses on some methods of using flash to launch CSRF attacks, hoping to inspire you.
Well, this topic is that we are too old, but we understand it too late.

0 × 01 use flash to initiate CSRF attacks

Flash features are rich, and of course there are APIs for sending requests to any site, in addition, the sent request will inherit the Session of the current browser-that is, we can use flash instead of js to control the browser to send requests to the target URL, which achieves CSRF. For example, loadVariables in Flash 8 and sendToURL in Flash 9 can all implement this function (select "only access network" for local playback security during compilation ").
For example, the following code:

Import flash.net. URLRequest;
Import flash. system. Security;
Var url = new URLRequest ("http://www.baidu.com/lake2 ");
Var lake = new URLVariables ();
Lake = "a = lake2 ";
Url. method = "POST ";
Url. data = lake;
SendToURL (url );
Stop ();

After compilation, you will find that it will POST data to Baidu. If your machine has a cookie of baidu.com, the cookie will also be sent, here we can bypass the privacy and security restrictions of IE. If you send data directly to baidu.com through img or iframe, the cookie will be blocked.
I also wrote a flash program to implement this type of attacks. refer to the previous CSRF article.

0 × 02 surpassing JavaScript Hijacking

JavaScript Hijacking is actually a type of CSRF, but it focuses on the use of the current session identity to get the content returned in JS form, and then get the sensitive data in JS. A typical vulnerability scenario is that some Web programs that provide JS interfaces for ajax may output current user data to JS.
Flash is much simpler, because flash 9 URLLoader can send requests and obtain returned data (similar APIs are available in flash 8 ).
Use the following as code to demonstrate loading the http: // www.0 × 54. org/lake2/flash/get.txt page:

Import flash.net .*;
Var myloader = new URLLoader (new URLRequest ("http://www.0x54.org/lake2/flash/get.txt "));
Myloader. addEventListener (Event. COMPLETE, test );
Myloader. load ();
Function test (event: Event ){
Var ResponseText: String = myloader. data;
Text1.text = ResponseText;
Stop ();
}

The compiled flash file is http: // www.0 × 54. org/lake2/flash/flashgetdemo.swf. In other words, the content of get.txt is displayed in flash.
JavaScript Hijacking can only get scripts, while flash can get the entire webpage. In addition to sensitive information, it can also bypass the rules that use form elements to defend against CSRF. For example, some websites put the uid in the hidden domain of the post to defend against CSRF. The uid cannot be obtained using third-party JS, but the uid in the page can be obtained using flash.
But don't be too happy. In this case of loading other pages, flash is limited by cross-origin policies.

0 × 03 cross-domain flash Policy

Adobe uses a cross-domain policy to restrict the loading of any pages from flash.
The so-called flash cross-origin policy file is the crossdomain. xml in the root directory of the site. This XML file configures the resources of the current site to allow flash loading from which domains. When flash loads resources of a site, if the target does not have a site with itself, flash automatically accesses the crossdomain under the target site and directory. xml file, if crossdomain. the allow-access-from domain tag in xml contains the website where flash is located, so flash can load the content.
A crossdomain. xml file may be like this:

<? Xml version = "1.0"?>
<Cross-domain-policy>
<Allow-access-from domain = "* .example.com"/>
<Allow-access-from domain = "www.friendOfExample.com"/>
<Allow-access-from domain = "192.0.34.166"/>
</Cross-domain-policy>

The above policy allows the flash from * .example.com, www.friendOfExample.com and 192.0.34.166 to load resources.
If the crossdomain. xml file does not exist on the site, flash can actively load other XML files of the target site as cross-domain policy files. For example, in Flash 9, you can use Security. loadPolicyFile to load other files of the target site as cross-domain policy files. If the cross-origin policy file is not licensed, sorry and flash cannot load the content of the site.

0 × 04 Cross-Domain Policy bypass flash

To implement CSRF, we may need to obtain the content on some pages of the target site. In this case, we have to find a way to bypass the flash Cross-Domain Policy.
The simplest case is that the target site itself has no security awareness. If you allow any flash to load the content, there is nothing to say (allow-access-from domain = "*").
In addition, if the root directory of the target site does not contain crossdomain. xml, you can find the file to be uploaded and upload a file in the same format, and then load it with Security. loadPolicyFile. It seems that flash is determined by Content-Type, so the text Type is valid.
The last case is that there is crossdomain. xml and it is well configured. In this case, it is a little troublesome. We can find out whether the website that supports flash loading can upload files and upload the specially crafted flash. It doesn't matter if the suffix is used: Any suffix can be used to call flash with the object label; other extensions, except jpg, jpeg, gif, and other suffixes, can be used to call flash with embed.

0 × 05 flash restrictions

Flash's network functions are too powerful, so it also has a set of restrictions. Set the allowNetworking parameter in the enable flash labels <object> and <embed>.
The allowNetworking parameter has three values: all, internal, and none.

· All -- allow all network APIs
· Internal -- cannot call browser navigation or browser interaction APIs. For example, getURL (flash8) and navigateToURL. You can still send external requests and load content
· None -- disable any Network API. The world is quiet, but flash functions will be weakened. For example, a flash MP3 player cannot be used.

For more information about which functions are prohibited by each option, see The ActionScript manual. It should be noted that if allowNetworking is not set, the default value is all. If the swf file is directly accessed without calling the webpage, allowNetworking is all.

0 × 06 Windows Media Player risks

We can call Windows Media Player on the webpage to play videos. Er, if you have installed the flash control, Windows Media Player also plays flash. If flash contains a script for sending data externally, it will also be executed-probably like allowNetworking is set to internal. This is an excellent CSRF carrier.
The allowNetworking parameter does not limit the flash called in Windows Media Player. It seems that there is nothing to limit it. For Web programs, this hidden danger is terrible.

0 × 07 Preventive Measures

After learning about the threat, it's easy to look at the defense methods.
In Web programs, you can determine the source of the request: We know the referer from the normal page, the request referer from flash is null or the swf file address (the API directly sending the request does not contain a referer, And the referer sent by the API for loading the page is the flash file address ). In addition, the x-flash-version ID is also included in the HTTP header when flash sends a request.
In terms of configuration, you must note that you can set the allowNetworking value based on business characteristics to control the flash Address. Do not use Windows Media Player to develop a flash Player. Use crossdomain in the site root directory. the xml file must be configured to be as accurate as possible to the subdomain to reduce the attack surface.
If you do not consider the user experience, it is best to use a graphic verification code in a particularly sensitive area.

0 × 08 postscript

If you have any comments, please send an email to lake2 # 80sec.com. BTW, The CSDN mailbox has been scrapped -_-!!
The content on this site is original. For reprinted content, be sure to keep your signatures and links!
CSRF with Flash: http://www.80sec.com/csrf-with-flash.html