Friday, February 20, 2009
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:
-----Original Message-----From: RSnake [mailto:email@example.com] Sent: Wednesday, February 18, 2009 4:18 AMTo: Nilesh Kumar (India)Subject: Re: Clickjacking
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> invisible div tag exactly over the button to be clicked. So user can see> the legitimate button in the background and clicks it whereas he> actually clicks invisible div tag over it and get redirected to another> malicious site.>>
Yes, this is one form of clickjacking.
And this is what Jeremiah says via LinkedIn mail:
On 02/18/09 7:51 AM, Jeremiah Grossman wrote:--------------------Case 1 most closely resembles Clickjacking. The following white paper will have more details and diagrams.
I forwarded the responses to Mozilla and finally they are again verifying their facts.Thanks to RSnake and Jeremiah for their encouraging words!
Friday, February 13, 2009
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.rorsecurity.info/journal/2009/2/11/mime-sniffing-in-ie-enables-xss-attacks.html
Thursday, February 12, 2009
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 the page in a
There are efforts to make Firefox too compatible to it .
But for the time being, Firefox users can use the a plug in ClearClick by NoScript.
Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning",
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's no way of doubt but clicking it once takes user to another site.
Google accepted it,others not accepting it.
Mozilla assumes it as URL rewriting via onClick event handler. I wrote back to Mozilla:
Dear Mozilla Team,
Thanks for the quick response.
Regarding the first example (click.html) I have sent , the exploit is not the issue but the browser executes the exploit is the real issue.Google has accepted the exploit being executed in their chrome browser as vulnerable to clickjacking ( you might have gone through several articles regarding it).
I used the same exploit to test with your latest Firefox 3.1 beta 2, I found that it’s executing successfully. I used same exploit with Opera 9.63 and was executing in that browser.
That’s why I brought it in your notice.
Anyways everyone has his own theory. I am not claiming myself to be expert on the issue but as Mozilla said to me:
"Clickjacking is when a user clicks on what they think is a button on a random site (i.e. attacker's site in the URL bar) but they are actually clicking buttons on another site like their bank without realizing it."
But again I am getting different theories from different vendors about clickjacking. So I will now just sit back and wait for the final concluding clickjacking definition and then only go for further research.
Wednesday, February 4, 2009
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 happens. I also pointed them in support of my claim that the attacks are not possible in updated Opera 9.63. Since the product is in beta phase their efforts are to make the thing safe.
Thank you for contacting us with this information. We are currently tracking it regarding clickjacking and we are investigating various strategies for mitigating this type of attack. Should any questions arise regarding the material you provided, we will certainly contact you.
Mozilla Security Group
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.
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. For example, there's an attack you could term "cookie stuffing" whereby bombarding the victim's browser will knock out cookies for authenticated sites and effectively log the user out. There are other attacks that make it of questionable benefit to address this on Google's end.
2) Images redirector
Your report appears to be similar to a 2008 public discussed thread that we are tracking:
We always monitor for redirector abuse and will act if we see any prior to the browser makers fixing up their model in this area.
Good mindset though, we appreciate it!
Chris, Google Security Team