How does it work?

A website must take a parameter to be used as a function name and then execute it as Javascript. This is commonly seen in JSONP implementations where a callback parameter is defined so that the website knows which Javascript function to return data to. A vulnerable instance might look like the following PHP code:

https://example.com/main

<?php

echo ‘<script src="https://example.com/jsonp?callback=’ . $_GET[“userParam”] .‘ “>’;

?>

In the above code snapshot, user input is directly getting injected in a script tag. The JSONP endpoint (https://example.com/jsonp) will return data that looks like this:

userParam({ jsonp : data }) // where `userParam` is whatever the user specified via the earlier GET parameter

Please note that the example code snippet listed above is vulnerable to XSS and other attacks, since user-controlled data is directly being injected in Javascript execution context.

In typical production environments, the ideal approach would be to define a safe callback function that implements whitelisting to accept only alphanumeric characters for such user generated input. This approach would typically suffice to prevent against XSS and other JSONP based Rosetta Flash vulnerabilities. However, this approach would not protect against SOME attacks. In fact, it is possible to navigate the DOM by using builtin methods mentioned earlier, such as firstElementChild, lastElementChild, and nextElementSibling. This allows an attacker to navigate to any element on a page with Javascript methods and interact with them.