Reverse Clickjacking

[dekeeu]

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.

<script>    var params = location.search.parseQuery();    var query = params["q"] || "Regina Spektor";    var script = document.createElement("SCRIPT");    script.src = "https://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=" + query + "&callback=handle_search_result";    document.body.appendChild(script);    window.handle_search_result = function (json) {...    };    window.delete_user_data = function () {...    };</script>

You can play around with it at - jsFiddle demo and modify it at Edit fiddle - JSFiddle. For a real-world example, take a look at Paul's blog post at @Paul_Axe : Two stories about XSS on Google.

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 - jsFiddle demo.

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

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

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

- jsFiddle demo.

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 - jsFiddle demo and the page with interesting button is at - jsFiddle demo. We construct our exploit as follows:

<iframe src="http://fiddle.jshell.net/D5nZ7/1/show?q=elephants%26callback=parent.frames.btn_frame.document.body.firstElementChild.click%23" name="vuln_frame"></iframe><iframe src="http://fiddle.jshell.net/g5P9H/1/show" name="btn_frame"></iframe>

See the code live at http://jsbin.com/vifuholi/1/edit.

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.

Sursa: https://plus.google.com/u/0/+AleksandrDobkin-Google/posts/JMwA7Y3RYzV?cfem=1