| Name |
Flash Injection |
|
| Likelyhood of attack |
Typical severity |
| High |
Medium |
|
| Summary |
An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker. |
| Prerequisites |
The target must be capable of running Flash applications. In some cases, the victim must follow an attacker-supplied link. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Find Injection Entry Points] The attacker first takes an inventory of the entry points of the application. |
- Spider the website for all available URLs that reference a Flash application.
- List all uninitialized global variables (such as _root.*, _global.*, _level0.*) in ActionScript, registered global variables in included files, load variables to external movies.
|
| 2 |
Experiment |
[Determine the application's susceptibility to Flash injection] Determine the application's susceptibility to Flash injection. For each URL identified in the explore phase, the attacker attempts to use various techniques such as direct load asfunction, controlled evil page/host, Flash HTML injection, and DOM injection to determine whether the application is susceptible to Flash injection. |
- Test the page using direct load asfunction, getURL,javascript:gotRoot("")///d.jpg
- Test the page using controlled evil page/host, http://example.com/evil.swf
- Test the page using Flash HTML injection, "'><img src='asfunction:getURL,javascript:gotRoot("")//.jpg' >
- Test the page using DOM injection, (gotRoot(''))
|
| 3 |
Exploit |
[Inject malicious content into target] Inject malicious content into target utilizing vulnerable injection vectors identified in the Experiment phase |
|
|
| Solutions | Implementation: remove sensitive information such as user name and password in the SWF file. Implementation: use validation on both client and server side. Implementation: remove debug information. Implementation: use SSL when loading external data Implementation: use crossdomain.xml file to allow the application domain to load stuff or the SWF file called by other domain. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-184 |
Incomplete List of Disallowed Inputs |
| CWE-697 |
Incorrect Comparison |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-137 |
An adversary manipulates the content of request parameters for the purpose of undermining the security of the target. Some parameter encodings use text characters as separators. For example, parameters in a HTTP GET message are encoded as name-value pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in these parameters, then they can inject special characters used in the encoding scheme to add or modify parameters. For example, if user input is fed directly into an HTTP GET request and the user provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a new parameter (new_param) is also added with a value of myValue. This can significantly change the meaning of the query that is processed by the server. Any encoding scheme where parameters are identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET encoding used above is just one example. |
| CAPEC-248 |
An adversary looking to execute a command of their choosing, injects new items into an existing command thus modifying interpretation away from what was intended. Commands in this context are often standalone strings that are interpreted by a downstream component and cause specific responses. This type of attack is possible when untrusted values are used to build these command strings. Weaknesses in input validation or command construction can enable the attack and lead to successful exploitation. |
|