|
|
||||||
| Thursday, September 09, 2010 | News | Advisories | Partners | Support | Contact Us | |
|
|
||||||
| Home | Large Enterprise | MidSize | Small Business | Schools | Government | CERT/CIRT | Labs | Contact Us |
|
LiveSquare Security Team Advisories Return to the listing of advisories LSST [2008.20.136.1108] Flash Player ‘Global Security Settings’ Do Not Prevent Cross-Site Redirects Many developers assume that the Flash Global Security Settings will protect a user against XSS activity. The security sandbox should prevent a SWF from accessing any information that does not originate in the same specific domain as the SWF file itself. However, it is trivial for the SWF to redirect the entire page to any other domain, without asking for permission, requiring user action, or providing any notification. The Issue In common practice, many developers assume that the Flash Global Security Settings will protect a user against XSS activity. When a user has selected the ‘Always Ask’ option (which is the default config) in the ‘Settings… --> Global Security Settings’ area of the Flash Player, then a SWF file playing in the Player should be locked into its ‘security sandbox.’ Specifically, this sandbox should prevent the SWF from accessing any information that does not originate in the same specific domain as the SWF file itself. E.g. a SWF file from DomainA cannot retrieve data from DomainB, unless the user agrees to it. However, contrary to that logic, it is trivial for the SWF to redirect the entire page to any other domain, without asking for permission, requiring user action, or providing any notification. This can be used to take the user to a malicious site without their knowledge. In a simple example, a SWF file from DomainA plays a video, which is a progressively downloaded FLV file from DomainA. This is normal and allowable. However, when the video is complete, ActionScript automatically redirects the browser to a page on DomainB. This ActionScript can be invoked at any time while the SWF is playing. The page on DomainB contains javascript in the header that executes before the new page loads. So, to the user, the javascript may execute before the page visibly changes. Implications Many sites utilize data feeds from external sources. Very commonly, SWF-based advertising is provided by a third party and inserted into a site. anyinnocentdomain.com may serve up advertisements that are provided by a broker. The site owner may never see all the ads that are rendered on their site, as they are inserted remotely, and dynamically. The vulnerability lies in the possibility that a user could visit anyinnocentdomain.com and be transparently redirected to a malicious site. The user could naturally assume that anyinnocentdomain.com was responsible, when, in fact, there is no malicious code in their site. A fairly large example of this occurred in 2007, as detailed here: http://www.dynamoo.com/diary/malware-scan-newbieadguide-com-hijack.htm A Simple Measure Fortunately, there is a simple way to help prevent this. This is not called a ‘fix,’ because it is not clear if there are other vulnerabilities involved, but in our example case, this simple measure prevents the redirection. When creating the embed code to insert the SWF into the HTML, you can prevent page redirection by utilizing the ‘AllowScriptAccess’ parameter: In the object tag… more info from Adobe: http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_16494 Not Ideal in the Real World Unfortunately, in practice, this may not be so simple. Most advertisements that are served up by third-parties have built-in links that are fully legitimate, and necessary. By utilizing the ‘AllowScriptAccess=none’ parameter, you prevent the user from clicking on a legitimate ad to visit the advertiser’s site. Possible alternatives could include adding a text-based link near the ad, or using html to make the ad’s container a link, whereby you could inspect, verify, and sanitize destination URLs. This would provide some protections and accountability, but most third-party ad suppliers do not currently provide feeds in this manner. ScriptAccess blocking can be very useful in some instances, where there is no reason for the externally-sourced SWF to invoke links or re-directs. In such cases, it should be standard practice to include the extra parameters and prevent any SWF script access to the browser. New Solutions Needed These issues call attention to the need for new processes. Video streams, data streams, ad feeds, etc. that are provided to a website from 3rd parties should be monitored and sanitized in real time, before they are delivered to the user. Some technologies exist for this, while others are still needed. |
| Home | Large Enterprise | MidSize | Small Business | Schools | Government | CERT/CIRT | Labs | Contact Us |
