Nilesh Kumar

Today I got mail form Mozilla: We will work with RSnake and Jeremiah to refine our definition of Clickjacking. Thank-you. - -Dan Veditz Mozilla Security Team - -Dan Veditz Mozilla Security Team This was regarding my last mail to Mozilla in which I had sent an Advisory to Mozilla about the Clickjacking. But as always there was again slight differences between mine and their definition of Clickjacking.Then I verified the case with none other than RSnake and Jeremiah, who replied me: RSnake’s Response: -----Original Message-----From: RSnake [mailto:h@ckers.org] Sent: Wednesday, February 18, 2009 4:18 AMTo: Nilesh Kumar (India)Subject: Re: Clickjacking Answers inline. Nilesh Kumar (India) wrote:> Hi RSnake!> Thanks for quick response. I want your kind help regarding it a bit> more.>> I agree with your theory. But I want your comments regarding all the> three specific cases I have described.>> Case 1. Used a frame to load a website in background and overlapped an...

Today I was going through an interesting article. It was about executing XSS through uploading an image hiding script in it. This is not new and has been out there for quite some time. But IE handles it less responsibly whereas FF and Opera simply prints the URL and broken image respectively instead of executing the script. For example, in Google Page Creator , there is an upload section which can be used to upload image file or say files with only .jpg,.bmp,.png extensions. But hiding a script inside an image file with valid extension (. jpg ) gets uploaded successfully and gets executed....but only in IE not otherwise. This might me an expected behavior of Google pages but the point is the way IE handles it. Few months ago before publishing of this article, I and my colleague Chintan had found it and discussed about it. That gave a strike to my mind today while reading the article on Owasp , that this we are already familiar with. Anyways the article could be read on http://www.r...

Javascript is not necessarily needed to execute Clickjacking.JavaScript might make the attacker’s life easier, but it’s not inevitable to make the attack. Alternatively the attacker can use frame tags to load any site of their choice in the background and using another div tag redirect the user to any other site of choice. No role of Javascript here. Mitigation? Don't load frame in your browser in any case. all it takes is including this piece of javascript in your page: This works in most browsers, with Internet Explorer being a notable exception. IE8 comes with another new technique.The fix is actually very simple: it lets website owners include an extra tag in their pages that tells Internet Explorer the page is not supposed to be included in a frame. It’s called X-FRAME-OPTIONS; a value of DENY means the page should never be opened in a frame, and SAMEORIGIN only allows it to be framed within pages from the same site. Any other use will show a warning, and a link that opens th...

The more I read, the more theories I get on the topic. Everybody has his own theories about Clickjacking.There's no consensus on the issue. Clickjacking for one is URL rewriting for another,simple hyperlink jump for another. Even there are contradiction by the people on Aditya's PoC on clickjacking in Chrome browser. Even on Hackademix.net Giorgio Maone has took the PoC lilghtly. That again increased the mist around the issue. Then what is the real clickjacking? In facts, with "Clickjacking" we designate a class of attacks (also known as "UI Redressing") which consist in hiding or disguising an user interface element from a site you trust in a way which leads you to click it without knowledge of what you're exactly doing. That's what Aditya showed in his PoC. When you click the link you are redirected to another site of attackes' choice without knowledge of users. When hovering the mouse over link it shows the intended name of the site, there...

I discovered that the latest Mozilla Firefox 3.1 which is in beta phase is susceptible to Clickjacking Attack. I conducted the test using two mechanisms,first was using iframe tag in background and div tag, second was using mouse event handling function. In the first kind of attack, attacker can load any website in background and places a button exact above any button on website in background. Now social engineering comes into scene.Clicking the button created by the attacker actually fires the button exactly beneath it which user can't see. Thus user is performing two actions at a time. In the second kind of attack a link is provided to user directing to any well known website,even address bar of the browser will show the link of the well known website, but clicking it will lead user to any malicious site crafted by attacker. So the user will be clicking on attackers' link rather than his known link. I contacted Mozilla with the issue in their latest product showed how it ...

At last Google responded to my two queries today. I have been receiving a lot of mails from them but this one is substantial. First was in response with the issue I once arose with Yahoo also and second one was in response with my advisory written to Google. They say that once Hackers.org has also posted something like this in their blog. Some where they nearly accepts the things and some where underestimate as n non security issue. But I think..Security or Non security issue the implementation is wrong.Anyways I am happy they have given some reasonable answer. Hi Nilesh, Hope all is well with you. Chris here from Google's Security Team. A colleague of mine pointed out you have reported various security issues to us recently. Thank you very much for taking the time to do that, and I wanted to let you know where they stand. 1) Logout XSRF. We will continue to track this, but as a low priority. Unfortunately, logout XSRF is kind of endemic to the way the web works. F...