Probably the first critical update issued from Adobe about possibly vulnerabilities in the Flash player. The December issues listed can be found here. April sees a new Flash Player update to resolve some cross-site scripting problems in the current v115 Flash Player.
This article will give you all the info you need. If you are running version 9.0.115.0 you are fine for DNS rebinding and cross-domain policy file vulnerabilities. The update in April will cover cross-site scripting vulnerabilities in SWFs. To find out what flash player version you are running click here.
"XSS vulnerabilities are exploited when attackers lure users into clicking malicious links sent via email or on a Web page. If a customer is logged into an account on a Web site, and then clicks on a malicious SWF link, the attacker could gain access to the customer's session by appending script to the link."
- Adobe (Vulnerabilities in some SWF files could allow cross-site scripting, December 23, 2007)
It is common practice to pass in xmlFile as the query parameter and then set a FlashVar to indicate the location of the XML file to load. The xmlFile is loaded using some URL loader, XML object in AS2 and URLLoader in AS3. If this is passed using the query param it means anyone can link to the site and replace your xmlFile with a javascript: URL to perform some task other than what was originally intended.
Since Flash Player 8 allowScriptAccess which is an <object> property used for embedding the SWF, has changed from "always" to "sameDomain". This was done to avoid any javascript URLs to make calls to functions hosted on other HTML pages unless otherwise specified by the author. So by default if you don't specify this property, your HTML file and SWF file has to be in the same domain, i.e. security sandbox. In many cases testing a Javascript function from your local machine doesn't work as the SWF and HTML are viewed not to be in the same domain.
The update in April will only allow getURL, fscommand & navigateToURL to make Javascript URL calls. Any other networking API like NetStream or XML would not be allowed to make these external calls. This reduces the risk for injection.
Javascript communication
In the past you could use this with any networking API, like in the example above where the XML file location is replaced by javascript: URLs to perform an injection. The use of the Javascript URL is very common as it means we don't have to explicitly create a method on the HTML page. We can just write the entire method in Actionscript like so "javascript: window.open()".
In general it is better to use ExternalInterface for any SWF to JS communication. It is a better API and much safer.
Understanding cross-site scripting (XSS) vulnerabilities in SWF files
Cross-site scripting is when one website has a file which is trying to communicate with another file on another website. XSS is a very common practice as content is not always stored in one and the same location. It also opened the Flash Player for potential risks like script injection."XSS vulnerabilities are exploited when attackers lure users into clicking malicious links sent via email or on a Web page. If a customer is logged into an account on a Web site, and then clicks on a malicious SWF link, the attacker could gain access to the customer's session by appending script to the link."
- Adobe (Vulnerabilities in some SWF files could allow cross-site scripting, December 23, 2007)
Script injection
Although cross-scripting is a well known term it doesn't just refer to SWF to SWF communication. It also refers to SWF to HTML communication or more accurately SWF to Javascript communication and vice versa.It is common practice to pass in xmlFile as the query parameter and then set a FlashVar to indicate the location of the XML file to load. The xmlFile is loaded using some URL loader, XML object in AS2 and URLLoader in AS3. If this is passed using the query param it means anyone can link to the site and replace your xmlFile with a javascript: URL to perform some task other than what was originally intended.
Since Flash Player 8 allowScriptAccess which is an <object> property used for embedding the SWF, has changed from "always" to "sameDomain". This was done to avoid any javascript URLs to make calls to functions hosted on other HTML pages unless otherwise specified by the author. So by default if you don't specify this property, your HTML file and SWF file has to be in the same domain, i.e. security sandbox. In many cases testing a Javascript function from your local machine doesn't work as the SWF and HTML are viewed not to be in the same domain.
The update in April will only allow getURL, fscommand & navigateToURL to make Javascript URL calls. Any other networking API like NetStream or XML would not be allowed to make these external calls. This reduces the risk for injection.
Javascript communication
In the past you could use this with any networking API, like in the example above where the XML file location is replaced by javascript: URLs to perform an injection. The use of the Javascript URL is very common as it means we don't have to explicitly create a method on the HTML page. We can just write the entire method in Actionscript like so "javascript: window.open()". In general it is better to use ExternalInterface for any SWF to JS communication. It is a better API and much safer.
Resources
- http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html
- http://www.adobe.com/support/security/bulletins/apsb07-20.html
- http://www.adobe.com/support/security/advisories/apsa07-06.html
- http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html
Leave a comment