Lecture 8: Web Security Model

What this lecture covers

Earlier lectures in 6.858 focused on server-side security. This lecture turns to the browser, which now runs JavaScript, manipulates the DOM, makes asynchronous requests, and mixes content from many different origins inside a single visual page. The lecture asks how a browser should isolate content from different providers that share the same tab, and introduces the same-origin policy as the browser's answer to that problem.

After watching, you can define what an origin is, explain which client-side resources (cookies, DOM storage, the DOM tree, JavaScript namespace) the same-origin policy protects, and recognize several real attacks - MIME sniffing, cross-site request forgery, DNS rebinding, and clickjacking - that exploit gaps in that policy.

Key ideas

• Origin: a scheme, host name, and port together; two URLs share an origin only if all three match.
• Same-origin policy: JavaScript from one origin can generally only access resources belonging to that same origin, though many exceptions and edge cases exist.
• Frame: roughly analogous to a Unix process; each frame gets the origin of its URL and can adjust that origin only to a suffix of its own domain via document.domain.
• Cookies: associated with a domain and path chosen by whoever sets them; the browser automatically attaches matching cookies to every request to that domain, which is why stealing or forging requests with cookies is dangerous.
• Passive content (images, CSS): given zero authority by the browser, but a misconfigured parser (as in the MIME sniffing attack) can let an attacker turn "passive" content into executable code.
• CSRF (cross-site request forgery): an attacker predicts the exact request a victim's browser would send with valid cookies and tricks the browser into sending it; defended against with unguessable per-session tokens embedded in forms.
• DNS rebinding: an attacker first serves a page from attacker.com, then rebinds that domain's DNS record to a victim's internal IP address, letting attacker JavaScript reach machines it should not be able to.
• Clickjacking: a malicious page overlays an invisible frame (such as a Facebook Like button) over content the user intends to click, tricking them into an action on another site.

Walkthrough

Why the browser is hard to secure (2:05)

The lecture surveys how much the browser can now do: JavaScript execution, the DOM, XMLHttpRequest/AJAX, WebSockets, video playback, geolocation, and native code plugins. Each new feature expands the attack surface, and specifications like HTML, CSS, and JPEG are long, inconsistent, and inconsistently implemented across browsers, which is why sites like quirksmode.org exist to document browser disagreements.

Origins and the four rules of the same-origin policy (17:38)

An origin is defined as scheme plus host name plus port. The lecture walks through a worked example of a page assembling content from several origins (an ad, an analytics script, a jQuery library, inline JavaScript, and a Facebook frame) and states four rules: each origin owns client-side resources such as cookies, DOM storage, and a JavaScript namespace; each frame gets the origin of its URL; scripts run with the authority of their enclosing frame's origin, regardless of where the script file itself was fetched from; and passive content like images gets no authority. postMessage lets frames from different origins exchange messages if both opt in.

document.domain, cookies, and CORS (32:58)

A frame can only widen its origin to a suffix of its original domain by setting document.domain, and two frames can interact only if both set the same value or neither has changed it - a rule meant to stop a malicious subdomain from attacking its parent domain. Cookies carry their own domain and path and are sent automatically with matching requests; the lecture covers the secure flag and the public-suffix list that keeps sites like foo.co.uk from shortening their domain to the effectively single-owner co.uk. Cross-origin AJAX is blocked by default unless the server opts in with the CORS Access-Control-Allow-Origin header.

MIME sniffing and CSRF (28:56)

Older Internet Explorer versions inspected the first 256 bytes of a "passive" resource and reinterpreted it as HTML or JavaScript if it looked like one, letting an attacker disguise a script as an innocuous image. The lecture then explains CSRF: because the browser automatically attaches cookies to any request, a malicious page can trigger a bank transfer request the user never intended. The fix is to embed a random, unguessable token in forms so the server can reject forged requests.

DNS rebinding and clickjacking (1:01:40)

DNS rebinding lets an attacker register a domain, serve a page from it, then repoint that domain's DNS record (with a short TTL) to a victim's internal IP address, so the attacker's own JavaScript can probe or contact machines behind a firewall under the guise of same-origin requests. Fixes include preventing external names from resolving to internal addresses, or DNS pinning. Clickjacking exploits the fact that pixels have no origin: a parent frame can draw an invisible frame (like a Like button) directly over content a user intends to click. Defenses are frame-busting JavaScript (self !== top) or the X-Frame-Options response header.

Before you watch

• Review the browser client-server model and prior discussion of buffer overflows and privilege isolation (OKWS) from earlier lectures in this course.
• Basic familiarity with HTML, JavaScript, and HTTP requests/responses is assumed.

Check your understanding

1. What three components make up an origin, and why do http://foo.com and https://foo.com count as different origins?
2. Why can a script loaded from a different origin still execute with full authority in the page that includes it, while an image from that same origin gets none?
3. Walk through how a CSRF token in a hidden form field prevents an attacker from forging a money transfer request.
4. Why does DNS rebinding depend on the attacker's DNS server, not the victim's, and why does HTTPS make this attack harder?
5. How does clickjacking exploit the fact that "pixels don't have an origin," and what are two defenses against it?