Vulnerability Writeups  - 
Today, I’d like to describe a new technique we’ve come to call Reverse Clickjacking. The situation when this technique becomes useful typically arises when a user-controlled parameter is used when constructing a URL, and the parameter is not properly escaped. Consider the following code example.

    var params =;
    var query = params["q"] || "Regina Spektor";

    var script = document.createElement("SCRIPT");
    script.src = "" +
            query +

    window.handle_search_result = function(json) {
    window.delete_user_data = function() {

You can play around with it at and modify it at For a real-world example, take a look at Paul's blog post at

Notice there is a weakness in the code. The attacker-controlled "q" parameter is not URL-escaped when generating the search URL. OK, so how do we exploit this?  We can use weakness to inject additional parameters into the URL. More specifically, we can override the callback parameter, and call a function of our choice.

You'll notice that in the code snippet, we have a function called delete_user_data defined at the global level. We can call this using the JSONP callback to obtain a working exploit. Try this live at

More commonly, we don't have any dangerous global functions, but instead we do have buttons that do interesting things. Consider this code.

        <h1>Welcome to this website.</h1>
      <button id=delete_user_data_button onclick="delete_user_data()">Delete all my data!</button>

Since button in question has a ID that is a valid JavaScript identifier, we can call it directly, e.g. Otherwise we can navigate through the DOM using firstElementChild and nextElementSibling, i.e.

OK, so what can we do if the page containing the vulnerability does not contain any buttons or any interesting global functions? If we can find an interesting buttons on any other pages on the same domain, we can call them extending the technique described above. Suppose the vulnerable page is at and the page with interesting button is at We construct our exploit as follows:


See the code live at

If either of the pages disallow embedding using X-Frame-Options, IFrames will not work, but that is not a fatal problem. Instead, we can open a pop-up window to another page we control and navigate the opener window to the button page. In the new pop-up, we wait for the main window to load the button page, and then navigate ourselves to the vulnerable page, which will do the clicking by accessing the button through window.opener. In previous versions of Chrome, pop-up windows that were blocked by the pop-up blocker were nevertheless executed, though their window were hidden from view. An more recent versions, in other browsers, we need a real user click to launch the initial pop-up. If you guys know a bypass, let us know in the comments.  Code to do all this, along with clicking multiple buttons, is left as an exercise for the reader.

#ReverseClickjacking #XSS
Eduardo' Vela" <Nava>'s profile photoKrzysztof Kotowicz's profile photo
Add a comment...