Wednesday, June 03, 2009

Clickjacking 2017

The future: Long standing Web application security scourges such SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) are finally under control. Remaining buffer overflow issues are considered fossilized evidence of a prior era. Cyber criminals out of necessity have evolved their attack portfolios to include Clickjacking as a preferred method for tricking their victims into propagating malware, defrauding themselves, and initiating other forms a malicious acts. Clickjacking, a long-known and fundamental design problem in the way the Web works, had not until 2017 garnered the respect necessary to be taken seriously. Now with significant damage increasing and loses mounting, the issue has forced website owners and browser developers to scramble for solutions to a problem nearly a decade in the making. Or so the story may go should history repeats itself.

By tracking the seminal papers/events of the more widely used attack techniques, it takes somewhere between 6 and 9 years for the bad guys to scale their exploits and cause enough damage where defenders are compelled to react. For example, Aleph One’s “Smashing The Stack For Fun And Profit” was published in 1996, but it wasn’t until 2002 that Microsoft’s then CEO Bill Gates issued the famous “TrustWorthy Computing Memo.” A six year gap sparking the software security revolution. XSS experimentation began around 1997 with few appreciating its true power until 2005 (8 years). The Samy Worm, the first mass scale JavaScript malware Web Worm, infected over 1 million MySpace users in under 24 hours. In 1998 rain.forest.puppy published the first research into SQL Injection. Nine years later marked the beginning of mass Web page malware infections proving how truly vulnerable websites were. The first CSRF papers began appearing around the turn of the century, but no convincingly evidence of catastrophic attacks has yet to appear justifying remediation investment. So we wait, knowing full well it is only a matter of time.

Clickjacking, an issue known by some for at least several years as UI Redressing, it was not fully explored or advertised until 2008 with the Flash videojacking demonstration. While non-malicious experimentation is taking place targeting those such as Twitter, no major damaging incidents can be referenced. And perhaps there won’t be until sometime between 2014 and 2017 if historical timelines hold. If so, the upside is we have time to deal with the issue, but I doubt we will be any more prepared by then. More likely the problem will scale well beyond our control, just like the others, as Web-enabled devices increase exponentially built upon a system where security fundamentals are difficult to change. In the meantime I’m sure we will be having a lot of fun times dealing with XSS, SQLi, CSRF, Intranet Hacking, Flash Malware, Business Logic Flaws, and so on.


Raf said...

@Jeremiah: "Jeremiah-dahmus?"

kuza55 said...

"The future: Long standing Web application security scourges such SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) are finally under control. Remaining buffer overflow issues are considered fossilized evidence of a prior era."

Ahaha, you've got to be kidding yourself if you think that either buffer overflows are under control in *anything* besides the cores of core internet software or that (short of a massive overhaul of how developers write code) xss or csrf will be fixed in the next 6 years.

Seriously, buffer overflows are dead only in the sense of "critical internet infrastructure isn't shaking in it's boots, only because no-one is modifying the code, only auditing it".

Jeremiah Grossman said...

@kuza55 one can hope. And kidding myself, or a loose form of optimism, is what keeps me from being a 100% cynical bastard. :)

Anonymous said...

I saw no mention of heap overflows either. Work done by Nico W., Hawkes, and Hzon are still proving out that there's ways to exploit these even in the more protected OS's, and there still out their to be found.

There's still pleanty of mem corruption out there, and more being created every day.

Jeremiah Grossman said...

That's a good point. Probably just as well that I left it out then since I have no idea when/if heap issues will be gotten under control. My pain point was that as an industry we tend not to deal with new attack techniques when we first learn of them. Rather it takes nearly a decade for them to be fully understand, respected, and finally taken seriously.

Erich said...

"[...] are finally under control"

I wish I could agree with you but I have no hope that this time will ever come. Not as long as there are more that ONE web browser, ONE OS, ONE web programming language, ONE web server and ONE international institution double-checking the code - for the whole Net. Because if not, there will always be a weak link in the chain. So you see: no hope.

Saurabh said...

How would you achieve clickjacking attack in a web application which generated dynamic web pages. For example, a banking application has a static web page which has a "continue" button. Clicking on this button will send a request to server with some post parameters and the login page willopen up in a new window. In this case, is clickjacking possible? It is possible to load that login page directly in an Iframe or is it possible to capture the clicks on initial page and then somehow load the new login page in the same frame?
Looking forward to your response on this.

Jeremiah Grossman said...

@Saurabh in a banking application, typically an attacker would want to clickjack a previously authenticated victim to achieve maximum affect. If the victim is authenticated, the attacker would then iframe in the banking page that containing the button they'd want the victim to mistakenly click on.

Hope this clarifies things.

Saurabh said...

Dear Jeremiah,

Thank you for clarifying this. Much appreciated.

A part of my query is still bothering me though. Like I mentioned in my previous post, if a bank has a static first page which then opens up a new window which will contain a form for entering a username and password. This page will then display the menu for logged in user. Now, had it been a static page as well, It would have been easily framed by just passing the url. But in this case, it has to be a POST request with 4-5 parameters in request body. I am just wondering, how would the code for this clickjacking page look like? A piece of my code is like:

<@frameset framespacing="0" frameborder="no"@>
<@frame name="clickjacking" scrolling="no" src="" noresize="noresize" /@>

which does not work since this will send a GET request which is not supported by server and also the POST parameters are missing.

Would highly appreciate your view on this.

acheter kamagra said...

Comment voulez-vous atteindre clickjacking attaque dans une application web qui a généré des pages web dynamiques. Par exemple, une application bancaire a une page Web statique qui a un bouton "continuer". En cliquant sur ce bouton enverra une requête au serveur avec des paramètres de poste et la page de connexion willopen dans une nouvelle fenêtre. Dans ce cas, est clickjacking possible? Il est possible de charger cette page de connexion directement dans une iframe ou est-il possible de hd'origine, puis en quelque sorte la charge de la nouvelle page de connexion dans le même cadre

acheter kamagra said...

Je n'ai vu aucune mention des débordements de tas soit. Le travail effectué par Nico W., Hawkes et Hzon sont encore prouver que il ya des moyens d'exploiter ces même dans le plus protégé OS, et là encore leur être trouvé.