INFO2222 · Computing 2 Usability and Security
Web Application Security
Week 11 covers the classic web-application vulnerability classes and their defences: cross-site scripting (XSS), SQL injection, and inference attacks, all rooted in trusting user input. Tracing an injected payload to the query or script it produces and naming the correct defence (parameterised queries, output encoding, input validation) is a reliable exam item, and the symbolic-execution material carries over from software security.
What this chapter covers
- 01The shared root cause: never trust user input — validate and sanitise it, and encode output
- 02SQL injection: input concatenated into a query (e.g. alice' OR '1'='1) makes the WHERE clause always true → auth bypass
- 03SQL-injection defences: parameterised/prepared statements (never string concatenation) plus input validation
- 04Inference attacks: learning hidden data using only allowed queries (e.g. binary-searching a salary threshold)
- 05Cross-site scripting (XSS): injecting JavaScript that runs in other users' browsers (defacement, cookie/session hijacking)
- 06Reflected vs stored (persistent) XSS: a stored payload is saved and re-served to every viewer
- 07XSS defences: encode output to HTML entities (< → <, > → >), validate input, use frameworks with built-in escaping
- 08Input validation patterns (regex-restrict usernames, range-check integers) and symbolic execution's path-explosion limit
Trace an SQL-injection login bypass and fix it
- +1(a) The app substitutes the raw input into the string, so the database receives: SELECT * FROM users WHERE username = 'admin' OR '1'='1'. The injected OR '1'='1 breaks out of the intended single-value comparison.
- +1(b) The clause '1'='1' is always true, and OR-ing it into the condition makes the whole WHERE clause always true, so the query returns rows (typically the first/admin user) regardless of the real password check — an authentication bypass.
- +1(c) Primary defence: use a parameterised (prepared) statement, e.g. cursor.execute("... WHERE username = ?", (username,)), so the input is bound as data and can never change the query's structure. Never build queries by concatenating user input.
- +1Supporting defence: validate and sanitise input — for example restrict usernames to a safe pattern such as ^[a-zA-Z0-9_]+$ — so characters like the apostrophe used to break out of the string are rejected before they reach the query.
Key terms
- SQL injection
- Inserting malicious SQL through user input that is concatenated into a query, e.g. alice' OR '1'='1 making the WHERE clause always true to bypass authentication or expose/alter data. Defended by parameterised (prepared) statements plus input validation, never string concatenation.
- Parameterised (prepared) statement
- A query where user input is bound as a data parameter (e.g. WHERE username = ?, (username,)) rather than concatenated into the query text, so input can never change the query's structure. The primary defence against SQL injection.
- Cross-site scripting (XSS)
- Injecting JavaScript into a trusted site so it executes in other users' browsers, enabling defacement, session/cookie hijacking, malware delivery or phishing. Injection can be via script tags or event handlers on other elements.
- Reflected vs stored XSS
- Reflected XSS echoes an injected payload straight back in a response; stored (persistent) XSS occurs when the application saves the payload and re-serves it to every viewer, so it affects many users over time.
- Output encoding
- The main XSS defence: converting special characters to HTML entities (< → <, > → >, & → &, " → ") so injected text is displayed as inert text rather than executed as markup or script. Combined with input validation and framework escaping.
- Inference attack
- Learning hidden data using only permitted queries — no hacking. For example, if a query only returns 'found / not found', an attacker can binary-search a threshold (salary, age) to narrow a private value.
Web Application Security FAQ
Why do SQL injection and XSS share the same root cause?
Both arise from trusting user input and letting it change how something is interpreted. In SQL injection, concatenated input becomes part of the query's structure; in XSS, unescaped input becomes executable markup in a page. The unifying principle is 'don't trust user input': validate it (expect data, not code) and, on output, either bind it as a parameter (SQL) or encode it to inert entities (HTML).
How do parameterised statements stop SQL injection?
They separate the query's fixed structure from the user-supplied values. The database is given the query template with placeholders and the inputs as bound data, so an apostrophe or an OR '1'='1 in the input is treated as a literal value to compare, never as SQL to execute. Because input can no longer alter the query structure, the whole injection class is closed — which is why concatenating user input into query strings is the anti-pattern to avoid.
What is the difference between reflected and stored XSS?
Reflected XSS bounces an injected script straight back in the immediate response — for instance a search term echoed unescaped — so it typically requires luring a victim to a crafted link. Stored (persistent) XSS is worse: the application saves the payload (say in a comment) and re-serves it to everyone who views that content, so a single injection can hit many users. Both are defended by encoding output and validating input.
Can AI help me with web application security in INFO2222?
Yes, as a study aid. Sia can trace an SQL-injection payload to the query it produces, explain why parameterised statements close the vulnerability, walk through reflected versus stored XSS and the right output encoding, and reason about inference attacks. Use it to rehearse the vulnerability traces and defences for the security quizzes and exam; it does not do graded assessment for you, and the University of Sydney academic-integrity policy applies.
Exam move
Practise tracing payloads end to end. For SQL injection, take a concatenated login query, insert an OR '1'='1 style payload, write the exact resulting query, explain why it is always true, and name the fix (parameterised statements first, input validation second). For XSS, be able to show a script or event-handler payload executing in a victim's browser, distinguish reflected from stored, and give the output-encoding fix (< → <). Learn inference attacks as 'legitimate queries leaking secrets' and the input-validation patterns (username regex, integer range checks). Anchor everything on the single principle 'don't trust user input', which unifies the whole chapter, and remember the symbolic-execution path-explosion point carried over from software security. Confirm the exam scope in the Week 12 revision on Canvas.
Working through Web Application Security in INFO2222? Sia is AskSia’s AI Computer Science tutor — ask any INFO2222 Web Application Security question and get a clear, step-by-step explanation grounded in how INFO2222 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
