Despite waning support for ActionScript on mobile platforms, the inclusion of ActionScript animations in web applications is common. Typically these animations are in the form of embedded SWF files, either through directly serving this content, or through an intermediate application which loads the SWF files from a protected area of the web server. The following scenario is based on a real-life, and commonly found, example of cross-site scripting through a hosted ActionScript animation identified during a recent penetration test. The amMap (available from www.ammap.com), is a web-based HTML and JavaScript library which can be used to create interactive maps for websites and applications. Some older versions, and some common configuration errors when including amMap in websites, can lead to cross-site scripting vulnerabilities by using configuration files from external resources. In order to exploit these flaws, an attacker must first find the raw SWF file. This can be easily identified by searching in the source code for the SWF file extension, or through inspecting web application requests and responses in a web proxy, such as Fiddler or Burp. In this case, the raw file was available at the following URL:
https://<The amMap library includes a number of customisable settings, but the ones which were of particular interest during the test are as follows:>;/maps/ammap/ammap.swf
- data_file: this variable specifies the name of a data file to use as its source data. This can be a local file on the web server, or can be a remote file, hosted elsewhere.
- map_data: this variable can be used to directly specify map data as part of the embedding HTML, through the amMap URL, rather than using a local or remotely hosted XML data file.
It was possible to modify the “map_data” variable, specifying some simple, proof of concept HTML and JavaScript, rather than the actual data intended by the website owners. Please note that this script will only be executed if a user clicks on the country (Algeria) highlighted in the map.
https://<The following image shows that the injected HTML and JavaScript are invisible to the user:>/maps/ammap/ammap.swf?map_data=
If a user of the application clicks on Algeria, which is highlighted in the previous image, the script will execute, causing a proof of concept alert to be displayed. Please note that real-life exploitation of cross-site scripting tends to be far more subtle than this.
It is also possible to specify a crafted custom XML file through the variable “data_file”. An example malicious XML data file, malicious_ammap.xml, which causes a script to run for any country of the attacker’s choosing is shown below.
[…] […]This can then be specified with a direct call to the mapping library, or through an embedded HTML code block, by using a URL such as that shown below.
https://<<WebSite>>/ammap.swf? data_file:https://<<ExternalDomain>>/malicious_ammap.xml
As before, the script will be executed when a user clicks on an affected country. The examples listed above are a mere proof of concept to show that the website can be vulnerable to cross-site scripting flaws. A cross-site scripting attack works by manipulating content of a web application and trick someone else into opening that page. Basically the potential damage of this attack may impact user’s browser. For example an attacker would have to build a malicious link and place it in malicious websites, web forums or send it by email. Despite the fact that an attacker can steal user’s sessions and so gain access personal details or administrative functionality, organization reputations can also be affected by this attack if a client has personal information exposed as a result of this issue. In order to tackle this issue we need to keep in mind what kind of software we are dealing with. Whereas it is not possible to manage the source code due to license restrictions, as it happens in this case, we need to work around with other alternatives. As a best practice for this scenario I would recommend setting up a cross-domain security policy restrictions on the server. A cross-domain policy is an XML file that must be named crossdomain.xml. This policy should reside at the root directory, as shown below. With a view of restricting access to files originating from external domains, we need to include the required domain name into the “<allow-access-from>” tag. This will prevent any attempt to load raw data from any external domain other than the one specify in the crossdomain.xml file.
https://<<WebSite>>/crossdomain.xml