Testing for Clickjacking (OTG-CLIENT-009) - Revision history

Roy Vanegas: Some editing of the content to make it easier to read, and replacing inch- and foot-marks with proper quotes.

2016-05-19T03:14:14Z

Some editing of the content to make it easier to read, and replacing inch- and foot-marks with proper quotes.

Nvhaver: /* Client side protection: Frame Busting */

2014-12-01T19:28:43Z

‎Client side protection: Frame Busting

Nvhaver: /* Create a "proof of concept" */

2014-12-01T19:25:17Z

‎Create a "proof of concept"

Nvhaver: /* Create a "proof of concept" */

2014-12-01T19:23:23Z

‎Create a "proof of concept"

Nvhaver: /* Create a "proof of concept" */

2014-12-01T19:19:35Z

‎Create a "proof of concept"

Andrew Muller at 13:41, 8 August 2014

2014-08-08T13:41:50Z

Andrew Muller: Andrew Muller moved page Testing for Clickjacking (OWASP-CS-004) to Testing for Clickjacking (OTG-CLIENT-009): Align with Common Numbering

2014-08-05T12:14:12Z

Andrew Muller moved page Testing for Clickjacking (OWASP-CS-004) to Testing for Clickjacking (OTG-CLIENT-009): Align with Common Numbering

Jane O'Connor: Final edit

2014-05-19T12:24:21Z

Final edit

Show changes

Tomas Zatko: X-Frame-Options values

2013-12-15T23:40:22Z

X-Frame-Options values

Davide Danelon at 16:30, 1 December 2012

2012-12-01T16:30:27Z

@@ Line 3: / Line 3: @@
 == Summary ==
-"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.
+“Clickjacking” (which is a subset of “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting with seemingly harmless web pages. The term “Clickjacking” was coined by Jeremiah Grossman and Robert Hansen in 2008.
-A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.
+A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking a button that appears to perform another operation. This is a “client side” security issue that affects a variety of browsers and platforms.
-To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.
+To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed with CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (through, for example, social engineering). Like other attacks, a common prerequisite is that the victim is authenticated against the attacker’s target website.
@@ Line 15: / Line 15: @@
-Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.
+Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions they never intended to perform through an “ad hoc” positioning of the elements in the web page.
@@ Line 25: / Line 25: @@
 ===How to Test===
-As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.
+As mentioned above, this type of attack is often designed to allow an attacker site to induce users’ actions on the target site, even if anti-CSRF tokens are being used. So, it’s important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.
-We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.
+We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a “proof of concept” to exploit the vulnerability.
-The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
+The first step in discovering if a website is vulnerable is to check if the target web page could be loaded into an iframe.
 To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

@@ Line 125: / Line 125: @@
 </pre>
-* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.
+* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible with Chrome and Safari.
 Example:
@@ Line 190: / Line 190: @@
 <br>
 Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
-* <b>IE8 XSS filter</b>: this filter has visibility into all requests and responses parameters flowing  through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters.
+* <b>IE8 XSS filter</b>: this filter has visibility into all parameters of each request and response flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disables all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induce a false positive by inserting the beginning of the frame busting script into a request's parameters.
 Example:
@@ Line 248: / Line 248: @@
 <iframe src="http://target site"></iframe>
 </pre>
 ====Server side protection: X-Frame-Options====

@@ Line 354: / Line 354: @@
-The attacker's page may look a simple and harmless web page like the one presented below:
+The attacker's page may look like a simple and harmless web page like the one presented below:
 [[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]
-But playing with the CSS opacity value we can see what is hidden under a seemingly innocuous web page.
+But playing with the CSS opacity value we can see what is hidden under the seemingly innocuous web page.
 [[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

← Older revision		Revision as of 19:23, 1 December 2014
Line 326:		Line 326:


−	In the last step are planned security controls and then, if is ~~all~~ ok, the transfer is done. ~~Following is presented~~ a snippet of ~~the~~ code of the last step (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):	+	In the last step are planned security controls and then, if all is ok, the transfer is done. In the following listing a snippet of code of the last step is presented (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

	<pre>		<pre>

@@ Line 364: / Line 364: @@
-The clickjacking code the create this page is presented below:
+The clickjacking code to create this page is presented below:
 <pre>
@@ Line 426: / Line 426: @@
 The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.
 ==Tools==

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 "Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.
 A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.
@@ Line 26: / Line 24: @@
-== Black Box testing and example ==
+===How to Test===
 As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.
@@ Line 436: / Line 427: @@
 The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.
 == References ==
@@ Line 447: / Line 441: @@
 * Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
 * Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

← Older revision	Revision as of 12:14, 5 August 2014
(No difference)

@@ Line 208: / Line 208: @@
 ====Server side protection: X-Frame-Options====
-An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed.
+An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.
 The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

@@ Line 369: / Line 369: @@
 == References ==
 '''OWASP Resources'''
-* https://en.wikipedia.org/wiki/Clickjacking
+* [[Clickjacking]]
 '''Whitepapers'''