Secure Programming of Web Applications: Clickjacking
We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.
This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers"
Description
Using the HTML element "iframe" arbitrary web sites or URLs can be integrated into the own web site. This is the standard behavior of web browsers. The "same-origin policy" indeed prevents by default that, e.g., a JavaScript of the embedding site accesses the content of a third-party page. However, the web page in the iframe works exactly like it would be opened in an own browser window or tab. That means all cookies and hence open sessions are active - simply within the iframe but on a different web site.
This can be exploited by malicious pages to mislead and trick regular users to execute certain actions or transactions undetected.
This concerns especially web forms, functions and JavaScript triggers of web applications that perform data modification and transactions. Simple data queries are not affected.
Eventually, a successful attack in this case works based on "UI tricks". However, there are no limits for the attacker's creativity to do so. For instance, the content of an iframe can be positioned at a certain position, the iframe can be created without scrollbars with a certain size. This could result in just a visible button of the victim's page - embedded in the external / attacker's site.
Another possibility is using transparent UI elements to create unsuspicious graphics to click on but actually perform unwanted clicks on the victim's page.
Secure Programming:
There basically exist two solutions. It has to be noticed that in certain application scenarios it is indeed desired that a web application can be used within an iframe. However, in such cases the whitelisting philosophy has to be implemented as far as possible. That means that all domains which are allowed to use the web application within an iframe have to be explicitly defined.
1)
The HTTP header
X-FRAME-OPTIONS
is a browser directive which is supported by all modern browsers and restricts the default behavior - namely allowing embedding the own page everywhere. It supports the value "DENY" which forbids the embedding into iframes completely and the value "SAMEORIGIN" which allows the embedding solely into the own page / domain / URL.
"SAMEORIGIN" can be used, e.g., if a login form is made available under a certain URL and included in several sub areas of a web site using iframes. Correspondingly, there might be similar individual application scenarios.
2)
A JavaScript-based solution which allows for more flexibility. However, it requires JavaScript to be enabled on the client-side. In this case, the following generally available JavaScript variable is used:
top.location
With this, arbitrary verification functions can be built to check the URL(s) of the embedding site (including the iframe) for validity. If this way an unauthorized embedding is detected, multiple reactions are possible. For instance, a simple error page could be displayed instead of the intended content or the top location could be changed so that the own web application will be display - maybe with a warning included. At all events, the actual functionality will be limited accordingly.
Keywords
Clickjacking, Secure Programming, Web Applications, Web Application Security, OWASP, Software Development, IT Security, Awareness
Categories: IT Security Background articles Development/Java
Comments
Post your comment
Share
If you like this page, it would be a great thing if you share it with others:
reddit
Digg
StumbleUpon
XING
WhatsApp
Telegram