Skip to main content
Fix typos
Source Link
Matthew
  • 27.4k
  • 7
  • 92
  • 104
parametrparameter
AplicationApplication

You shouldn't forget about Flash ParametrParameter Pollution.

Flash ParametrParameter Pollution

orginaloriginal
parametr
Aplication

You shouldn't forget about Flash Parametr Pollution.

Flash Parametr Pollution

orginal
parameter
Application

You shouldn't forget about Flash Parameter Pollution.

Flash Parameter Pollution

original
Source Link
p____h
  • 1.6k
  • 7
  • 11

Everything here depends on the version of your Flash Player. Here's a list of stuff, which you should try on this .swf file.

Our first guess was Cross Site Scripting so we should try our hand at XSS, especially that we noticed one of the unsafe method: loadMovie.

Cross Site Scripting

There are a few types of unsafe functions. Each of them has different payload:

  • getURL - payload: javascript:alert('XSS')
  • load* (in this case: loadMovie) - payload: asfunction:getURL,javascript:alert('XSS') [asfunction works in this context until release Flash Player 9 r48]
  • TextField.htmlText - payload: <img src='javascript:alert("XSS")//.swf'> [.swf is very important here - other extensions won't bypass the internal filter of the Flash Player].

Cross Site Flashing

our second guess should be **XSF**. The first flash movie tries to load the second one. When it gain the access to the same part of the sandbox, we are vulnerable to XSF. This means, that we are able to load the external, evil flash file, which can lead to XSS or fake flash-movie (for example: fake flash-form, kind of phishing). Now let's think for awhile when we could get that flaws.

Flash Player 7 or later permits cross-domain scripting only between the same domain. We can load .swf files from different domains, but that files won't be able to exchange data. For more details you should check System.security.allowDomain.

Now let's talk about:

AllowScriptAccess

This parametr can be found inside `param` or `embed` tag and it decides about the ability to perform outbound URL access from within the SWF file. There are three possible values: - `sameDomain`: access to communication is allowed when .swf file and the embedding HTML page are in the same domain. - `always`: the same as `sameDomain`, but .swf file could also communicate with .swf from the different domain (than it is embed). - `never` - .swf file can't communicate with any page. Aplication layer protocol, domain name and port number define the origin. When .swf file gets JavaScript code to execute from the browser, it will be executed within the origin of embedding website. Let's consider two situations [`allowScriptAccess = sameDomain`]:
  • .swf hosted on A.com is embed in the HTML website on B.com: origin: B.com
  • B.com has an iframe which load .swf file from A.com: origin: A.com

The default value is set to sameDomain. It means that .swf without AllowScriptAccess attribute should be considered as the .swf with the sameDomain property. In 2008 it has been noticed, that sameDomain could lead to Cross Site Request Forgery. I really recommend you to read the blog-post about this (more details - here) and look at the PoC.

You shouldn't forget about Flash Parametr Pollution.

Flash Parametr Pollution

Not every .swf files can load without the orginal HTML. If the programmer forgot about the sanitization, we could inject global variables into flash:

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

URI: http://example.com/?flash=flash.swf?var=bum

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>