Create tresgdf.html

[maekuss]

No description provided.

[hacktron-app]

1 issue found across 1 file

Severity	Count
	1

View full scan results

[hacktron-app]

DOM-based Cross-Site Scripting (XSS) via Insecure postMessage Listener in tresgdf.html

The pull request introduces a new file testerror/tresgdf.html containing a DOM-based Cross-Site Scripting (XSS) vulnerability. The application registers a global message event listener via window.addEventListener('message', ...) but fails to perform any origin validation on the incoming event.origin.

The payload received from the event (event.data) is assigned to the incoming variable and then directly rendered into the DOM using the dangerous innerHTML sink. If this file is hosted on a web server, any malicious third-party origin can open the page (e.g., in an iframe or a popup window) and use postMessage to inject and execute arbitrary JavaScript code within the context of the vulnerable page's origin. This can lead to session hijacking, unauthorized actions on behalf of users, or data exfiltration.

Steps to Reproduce

// From an attacker-controlled origin:
const victim = window.open('https://victim-domain.com/testerror/tresgdf.html');
setTimeout(() => {
  victim.postMessage('<img src=x onerror="alert(document.domain)">', '*');
}, 1000);

Fix with AI

A security vulnerability was found by Hacktron.

File: tresgdf.html
Lines: 30-37
Severity: high

Vulnerability: DOM-based Cross-Site Scripting (XSS) via Insecure postMessage Listener in tresgdf.html

Description:
The pull request introduces a new file `testerror/tresgdf.html` containing a DOM-based Cross-Site Scripting (XSS) vulnerability. The application registers a global `message` event listener via `window.addEventListener('message', ...)` but fails to perform any origin validation on the incoming `event.origin`. 

The payload received from the event (`event.data`) is assigned to the `incoming` variable and then directly rendered into the DOM using the dangerous `innerHTML` sink. If this file is hosted on a web server, any malicious third-party origin can open the page (e.g., in an iframe or a popup window) and use `postMessage` to inject and execute arbitrary JavaScript code within the context of the vulnerable page's origin. This can lead to session hijacking, unauthorized actions on behalf of users, or data exfiltration.

Proof of Concept:
// From an attacker-controlled origin:
const victim = window.open('https://victim-domain.com/testerror/tresgdf.html');
setTimeout(() => {
  victim.postMessage('<img src=x onerror="alert(document.domain)">', '*');
}, 1000);

Affected Code:
    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), !accepted_risk <reason>, or !fixed (resolved). 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}