ExternalInterface.call(...), which implements a JavaScript bridge to the hosting page. It takes two parameters: the first one is the name of the JavaScript function to call. The second one is a string to pass to this function.
It is understood that the first parameter should not be attacker-controlled (of course, mistakes happen :-). It is also understood that there is no inherent harm in putting user input in the second parameter, if the callback function itself is not behaving stupidly; in fact, Adobe documentation gives an example that follows this very pattern:
...
ExternalInterface.call("sendToJavaScript", input.text);
...
Such a call would be translated to an eval(...) statement injected on the embedding page. This statement looks roughly the following way:
try {
__flash__toXML(sendToJavaScript, "value of input.text"));
} catch (e) {
"<undefined/>";
}
When writing the supporting code behind this call, the authors remembered to use backslash escaping when outputting the second parameter: hello"world becomes hello\"world. Unfortunately, they overlooked the need to escape any stray backslash characters, too.
So, try to figure out what happens if the value of input.text is set to the following string:
Hello world!\"+alert(1)); } catch(e) {} //
I reported this problem to Adobe in March 2010. In March 2011, after following up, I received the following response:
"We have not made any change to this behavior for backwards compatibility reasons."
Caveat emptor :-)
0 nhận xét:
Đăng nhận xét