November 8, 2013 · clickjacking cors websec

Practical uses of ClickJacking and Cross Origin Requests (OzBargain.com.au)

For those that don’t know, OzBargain.com.au is a deal sharing website in Australia which reaches approximately 1,000,000 unique visitors every month. People and store reps can post deals up, and really, it’s a win-win situation for the consumer and for the sellers.

Most security researchers are aware of clickjacking and the dangers of not implementing secure cross domain request policies – however, this blog post is just a little write up of some pretty applicable uses of these exploitation techniques that I found on OzBargain.

1. ClickJacking

Wikipedia’s lists clickjacking as “a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on”.

Websites which do not specify an “X-Frame-Options” header to be “SAMEORIGIN” (you may only iframe the page if it is on the same origin) or “DENY” (disallowing the framing of content all together) may be vulnerable to Clickjacking.

Since OzBargain did not have the X-Frame-Options header set, I was able to produce a PoC for a clickjacking vulnerability, which would essentially trick the user into upvoting posts on OzBargain, without being aware of it.

Here is a gif, demonstrating it:

gifPoC

Here is the code for the PoC:

I reported this vulnerability on the 20th of October 2013, and Scotty (Founder of OzBargain), fixed it on the very same day by adding the X-Frame-Options header.

I thank him for the way he treated the security issues and only can wish that other webadmins did the same.

2. Cross Origin Requests to OzBargain API

The other concerning issue that I found whilst looking through OzBargain’s API, was that it was not checking the origin of the requests made to the API. This meant that we could send authenticated requests to the API from different origins. The severity of this vulnerability far outweighed the severity of clickjacking, as this exploitation technique required no interaction – but rather just having javascript enabled and visiting a page which sent malicious API requests (e.g. up voting deals, down voting deals, etc.)

As promised in the title of the post, this vulnerability would have been a practical exploitation vector by someone using OzBargain as a way to post their deals. As soon as an OzBargain user would visit their deal, without consent, the deals website could send requests to the API acting as the OzBargain user to down vote any other deals competing with the malicious store.

Here is a little demonstration (GIF):

gifPoC2

Here is the code snippet for the above demonstration. Note: I used parts of code from here to construct this PoC:

Scott was able to fix this vulnerability very quickly as well. The OzBargain community should truly be glad that it’s building blocks are developed by a competent developer who responds promptly to any possible threats.

Thank you Scotty for fixing these vulnerabilities, and thank you for reading.

Comments powered by Disqus