The amMap library includes a number of customisable settings, but the ones which were of particular interest during the test are as follows:
- 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.
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.
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.