XSS Hunting (reflected, stored, DOM)

Tags: xss, dom, csp, ato

Level: intermediate

Method

1. Build a URL corpus

   Historical + crawled URLs with parameters. Dedupe with uro so you test endpoints, not values.

   waymore -i target.com -mode U -oU urls.txt; katana -u https://target.com -jc -silent | anew urls.txt; cat urls.txt | uro > urls.uniq.txt

   Copy

   Tools: waymore, gau, katana, uro

2. Marker, not payload

   Inject a unique string (vulnsXSS) into every param, header, and JSON field. Grep responses, including JSON and redirects.

   cat urls.uniq.txt | qsreplace 'vulnsXSS' | kxss

   Copy

   Tools: qsreplace, ffuf, kxss

3. Name the context

   HTML body, attribute, JS string, unquoted JS, URL, CSS, SVG, Markdown, template. The payload is chosen by context, not by a list.

   Tools: Burp Suite, Caido

4. DOM sources and sinks

   Read the JS. location, hash, postMessage, storage, document.referrer into innerHTML / html() / v-html / write.

   cat js.txt | jsluice urls; semgrep --config=p/javascript ./src-dump

   Copy

   Tools: jsluice, sourcemapper, semgrep

5. Stored and admin-only

   Profile fields, filenames, webhooks, support tickets, email-to-app. If only an admin renders it, it is still XSS with a clear victim.

   Tools: Burp Suite

6. CSP and cookie reality

   Does CSP block you? Is the cookie HttpOnly? Can you call an authenticated API from the XSS even if you cannot read the cookie?

Field notes

• Self-XSS is not a report unless you can force the victim into the sink (clickjacking, CSRF, copy-paste social is usually out).
• A working XSS on a cookied origin plus localStorage tokens is ATO. Write it as ATO, not as 'alert'.

References

• https://portswigger.net/web-security/cross-site-scripting
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection