Lecture 9: Securing Web Applications

What this lecture covers

Continuing from the previous lecture on the same-origin policy, this lecture goes deeper into how real web applications fail and how they can be defended. It opens with live demonstrations of the Shellshock bug and a cross-site scripting (XSS) attack, then works through defenses: browser XSS filters, HTTP-only cookies, domain-based privilege separation, content sanitization (Django templates), less expressive markup languages, and Content Security Policy (CSP). It then covers SQL injection, session management with cookies versus stateless authentication using Message Authentication Codes (as in AWS request signing), and a set of side-channel attacks that let a malicious site infer which other sites a user has visited.

After watching, you can explain why naive content sanitization fails, describe how CSP restricts where scripts and other resources can load from, contrast cookie-based and MAC-based (stateless) authentication, and recognize link-color, cache-timing, DNS-timing, and rendering-timing attacks that leak browsing history.

Key ideas

• Shellshock: a Bash vulnerability where a malformed function definition passed through an HTTP header used as an environment variable tricks Bash into executing attacker-supplied commands after the function definition.
• Reflected XSS: an attacker's script is embedded in a URL and printed directly into the response HTML; it executes only while the user has that URL open.
• Persistent XSS: malicious HTML or script saved server-side (e.g. in a comment or profile) runs for every visitor until removed.
• Content sanitization: escaping special characters (like <, >, ") before inserting untrusted input into HTML, as Django's template system does by default; it reduces but does not eliminate XSS risk because HTML/CSS/JS grammars are complex and browsers tolerate malformed markup.
• Content Security Policy (CSP): an HTTP response header that restricts which origins a page's scripts, images, and other resources may load from, blocks inline <script> blocks, and disables eval.
• HTTP-only cookies: a Set-Cookie flag telling the browser not to expose a cookie to JavaScript, which blocks cookie theft via XSS but not cross-site request forgery.
• Message Authentication Code (MAC) authentication: a stateless alternative to cookies (used by AWS) where the client signs each request with a shared secret key instead of sending a persistent session token.
• History-sniffing side channels: link-color inspection, cache-timing, DNS-timing, and render-timing attacks that let a malicious page infer which other sites a visitor has previously loaded.

Walkthrough

Live demos: Shellshock and XSS (0:00)

The lecture opens with two demonstrations. First, a toy CGI server that copies HTTP request headers into Bash environment variables is shown executing an attacker-supplied command via a malformed Bash function definition - the Shellshock bug. Second, a toy CGI server that prints a query-string value directly into HTML is used to demonstrate reflected XSS: a naive <script>alert('XSS')</script> payload is blocked by the browser's built-in XSS filter, but a malformed img"""><script> string confuses the HTML parser enough to bypass the filter and execute.

Browser XSS filters and privilege separation (14:16)

Browsers like Chrome and IE use heuristics (such as detecting a script tag embedded in a URL) to block likely XSS payloads, but these filters are incomplete and can be bypassed, and they cannot stop persistent XSS stored on the server. HTTP-only cookies stop JavaScript from reading a cookie but not CSRF-style requests. Sites like Google historically served user-submitted content from a separate domain (googleusercontent.com) so that an XSS bug in that content is contained away from the main domain.

Content sanitization and its limits (24:38)

Django's template system escapes characters like < and > into HTML entities so untrusted values can't break out of their intended context. This helps but is not foolproof: because HTML, CSS, and JavaScript grammars are ambiguous and browsers must tolerate broken markup to stay usable, clever payloads can still confuse the parser. A less expressive markup language, such as Markdown compiled to HTML, is easier to sanitize completely than full HTML/CSS/JS - though allowing inline HTML inside Markdown reopens the same risk.

CSP and SQL injection (34:44)

CSP lets a server declare, for example, that scripts may only load from self or *.mydomain.com; the browser then refuses any script reference outside that allowlist, blocks inline scripts, and disables eval and related dynamic code generation. The lecture then turns to SQL injection, showing how an unsanitized WHERE UserID = <input> query lets an attacker terminate the query early and append commands like DELETE TABLE. The fix is rigorous escaping of untrusted input before it reaches the database, which frameworks like Django provide but developers sometimes bypass for performance.

Cookies and stateless MAC authentication (46:03)

Session cookies map a random session ID to server-side user state, making the cookie a high-value target for theft. As an alternative, the lecture explains stateless authentication using Message Authentication Codes, illustrated with AWS request signing: each request carries the user's ID in the clear plus a signature computed from a shared secret key over key parts of the request (verb, content hash, content type, date, resource path). This avoids a persistent session token but raises its own issues, including where the secret key is stored and how requests are protected from replay (partly addressed with expiration timestamps). DOM storage and client-side certificates are mentioned as further cookie alternatives.

GIFAR, protocol parsing bugs, and history-sniffing side channels (1:03:38)

Inconsistent URL parsing between Flash and browsers could let a script from one origin run with another origin's authority. The GIFAR attack combined a GIF (parsed top-down) with a JAR/Java applet (parsed bottom-up) into one file that passed image-upload validation but executed as code when referenced by an injected applet tag. The lecture closes with covert channels that leak browsing history: reading visited-link colors (now blocked by browsers lying about link state to JavaScript), timing how fast cached resources load, timing DNS resolution for candidate hostnames, and timing how quickly a browser renders previously visited content - each of which an attacker's page can use to infer what sites a visitor has been to.

Before you watch

• Watch the previous lecture on the same-origin policy, cookies, and CSRF, since this lecture builds directly on those concepts (especially in the cookie and MAC discussion).
• Basic familiarity with HTTP requests/responses, shell scripting, and SQL queries is assumed.

Check your understanding

1. Why did the toy CGI server demo make it possible to execute an attacker's command by setting a custom HTTP header, and how does this relate to how Shellshock affected real servers using Apache?
2. Why can browser XSS filters and server-side content sanitization reduce but not eliminate cross-site scripting risk?
3. How does a Content Security Policy header stop an XSS payload from exfiltrating data to an attacker's domain, and why does it also disable eval?
4. In the AWS-style MAC authentication scheme, what does the server need to know in order to validate a signed request, and what problem does an expiration field help mitigate?
5. Name two different side-channel techniques (other than reading link colors) that let a malicious site infer a user's browsing history, and explain why each works.