UI Redressing (CLICKJACKING) – threat to online banking and other web applications
2014/02/17 Dodaj komentarz
There is a still growing interest in attempts to exploit not only the security relevant code flaws in the web browsers software, but rather design weaknesses and deficiencies of security models, based on which they normally operate. The escalation of some sort of client side security violation attempts to break the web applications security is expected to take place in the nearest future. This is because there is a growing interest among the attackers in exploiting web browsers security deficiencies very frequently accompanied by number of code-flaws based vulnerabilities. The attackers focus is nowadays more and more frequently directed on circumvent application security through the family of attacks called UI Redressing or clickjacking.
Where the problem actually is?
UI Redressing (clickjacking) is the kind of malicious activity performed by covering, open in an IFRAME, legitimate attacked application, by another IFRAME with specially crafted exploit-application (for instance on-line game or something similar) and – further – navigating the victims through the window and forcing them to click on the specific window areas in order to finally capture and later handle them in the context of the not visible layer – the attacked application, which lies beneath the exploit-application.
In practice, the attack scenario looks like that: the victim usually receives an e-mail from the attacker or post is published on the social networking site with a link to the online bank and also some other applications or interactive multimedia content. A link to the bank usually contains some advertisement like for instance: „Look how attractive offer has been prepared specially for you by your bank” due to simply effectively catch your attention. The second link presented is – of course – a link to the exploit-application, usually some on-line game, video or Flash animation. Then the user clicks on the first link and is redirected instantly to the legitimate internet bank’s website. The potential victim logs on to the bank and – leaving open session – then goes to the next link, let us assume, that one pointing to a malicious on-line game. The problem here, at this stage, is that there are simultaneously opened sessions to the on-line bank within one IFRAME window and an exploit-application executed within another IFRAME located on top of the former one. In the other words, the exploit-application IFRAME covers perfectly the legitimate application window, but all of the clicks and other interaction with graphical user interface handling is made at the level of the attacked application, residing on the hidden layer. Now the attackers attracts the victims by some way to perform some clicks, then hijacks them and serve in the context of attacked application, for instance online bank running underneath. The outcomes can be potentially troublesome. Forcing the victim by the attackers to make fraudulent transactions, without additional social engineering seems to be virtually impossible, due to the requirement to authorize the transaction through entering authorization code or generating digital signature. However, attacker can, for example, make an attempt to modify the predefined contractors database or can try to change the database of predefined transaction. That attacks attempts most probably will also fail, because such changes require a two-factor authorization in every secure on-line banking application. Nevertheless the reputational risk remains if you won’t eliminate the possibility to open your application within IFRAMEs. It will result in publishing in Internet any kind of so called proof-of-concepts of attacks on your site, on the wave of growing interest in the topic.
Serious risk occurs in a case when the role of an exploit application plays specially crafted phishing iframe prompting the user for additional step of authentication or authorization of particular changes in personal information or account settings by SMS code, while underneath is located the form of money transfer. The one-time-code taken over by the exploit application is used subsequently to withdraw funds from users’ banking account.
How to defend against them?
The defense is called frame busting, which in practice consists of either (1) preventing applications (on-line banking or web site) from running within IFRAME or (2) prevent one IFRAME with legitimate application open to be covered by IFRAME with malicious exploit-applications.
The first form of defense can be implemented on web server or a reverse-proxy server to send to the user’s browser the HTML messages with the X-FRAME-OPTIONS header set to „deny”.
The second way is modify the web application code to include the following script in at least some of most ‘risky’ pages (for instance on each application data entering forms):
This script prevents attacked application from being covered by IFRAME with malicious exploit-application.
The advantage of the first method of protection from clickjacking is the relative simplicity of its implementation. The main disadvantages are (1) that not all of the web browsers (especially the older ones) support the X-FRAME-OPTIONS header and (2) that this header must be explicitly set for each response to web page requests from the server. Thus, the application, web server or a reverse-proxy server must be able to send such a header. The disadvantage is also, that even if an application or web server can do this, it sometimes happens that some kind of reverse-proxy server, interfering with the contents of the packets flowing through it, may remove these headers.
The advantage of the second protection way is independent from the browser compatibility issues. The major disadvantage is however the need to modify the code of the application.