Everyday we click on some kind of button in our Web browsers.
It could be a simple “Yes” button to agree to something or a “submit” button for your password. But do you know what you’re actually clicking? If you’re not careful, you could become a victim of a clickjacking attack.
“This vulnerability lets an attacker transparently collect user clicks and that enables them to force the user to do all sort of things from adjusting user settings to unwittingly visiting Web sites that might have malicious code,” Jeff Moss, founder of Black Hat stated during an live Webinar on Thursday.
“It’s sort of like the DNS cache vulnerability that [security researcher Dan] Kaminsky found where at first you think you understand all the implications, but the more you think about it the greater the problem becomes, sort of this daunting realization that things are screwed.”
Whitehat security founder Jeremiah Grossman gets the credit for reporting the clickjacking security issues to Adobe earlier this year. That led to an update for its Adobe Flash product. Grossman said latest Flash 10 player does a good job of protecting against clickjacking.
But browsers still have holes that leave users vulnerable. Clickjacking can happen via malicious IFRAMEs,
“Shutting off IFRAME gets rid of some of the issues, but also breaks the whole revenue model of the web as it turns off some advertising,” Jeremiah Grossman, founder of Whitehat Security said. “I don’t think that will be a default feature in any Web browser any time soon.”
Eric Lawrence, security program manager on Microsoft’s Internet Explorer team, echoed Grossman’s sentiment about the issue. Lawrence, who also participated in the live Black Hat Webinar, noted that IFRAMEs are critical for many mashup scenarios as well as some forms of Web advertising. Still, Lawrence added, focusing on IFRAME is important because if IFRAMEs can be better isolated than the risk from clickjacking can be mitigated.
“The clickjacking attack is a super interesting attack because it is one of the hardest things for a browser to address,” Lawrence said. “Because it is essentially the browser working in the way it was designed and intended; there is a side effect that has a security impact that we now have to find a way to mitigate against. This is one of a few things … putting the browser vendors on the defensive –where we have to find a way to not break the web while at the same time mitigating the vulnerability.”
Grossman noted that regular FRAMEs
Though the problem affects end users of Web sites, at the root of the clickjacking attacks are Websites themselves, which are often attacked so that the exploit code that can hit browser can be deployed.
This is why Grossman and Lawrence stressed proper Website server security. Microsoft’s next browser, IE 8, will include technology that will let different browser tabs run different processes, Lawrence said. The idea is that processes don’t jump tabs which could potentially mitigate risk. A similar approach is used by Google’s Chrome browser as well.
For Mozilla Firefox users there is an add-on called No Script that users can deploy. Grossman said it identifies all running scripts on a page and could be used to block potential clickjacking attempts.
Even being logged into a secure site via SSL
Lawrence suggests that users not log into sites they don’t care about, while they are logged into sites they do care about. For example, it might not be a good idea to keep a tab open with your bank while browsing on a social networking site. The risk is that information from one tab could potentially be stolen by a script running in the other tab.
There is also a W3C proposal for XML over HTTP (XHR) cross site requests that could potentially end up preventing clickjacking as well. The W3C XHR approach was at one time intended to be inside of Mozilla Firefox 3 but is now being targeted for inclusion in the Firefox 3.1 release.
The W3C cross site XHR approach is intended to define a mechanism by which Web developers can safely provide cross-site Web resource access. The specification will let developers define via an HTTP header or an XML instruction which sites are allowed read-access and which are not. Whitehat’s Grossman wasn’t sure that the W3C specification could mitigate clickjacking, while Microsoft’s Lawrence could envision a scenario where it could.
“If you look at it in a generic way the W3C proposal is to use a content security policy for XHR to say this type of request is allowed and this one is not,” Lawrence explained. “You could imagine that a site could come up with a policy that says none of my content may be framed by someone else. If the browser supported such a policy than clickjacking could be mitigated through that.”