Browser Security Models

01 //

Goals of Web Security

Browser security aims to let users browse safely, protect sensitive information, and support secure web applications with the same security properties as standalone applications.

Browse Safely

No Stolen Information

Site A cannot compromise the session at Site B. Isolation between origins.

Secure Web Apps

Application Security

Applications delivered over the web should achieve the same security properties as standalone apps.

Basic Questions

How do we protect the page from ads, libraries, CDNs, and extensions?
How to share data with cross-origin pages?
How do we protect one user from another's content?
How do we protect the extension from the page?

Modern Websites - Acting Parties

Page developers

Library developers

CDNs

Ad providers

Service providers

Extension developers

Other users

02 //

Web Threat Models

Three attacker models: Web Attacker (controls malicious site), Network Attacker (intercepts network), Malware Attacker (escapes browser, runs under OS). Malware is most lethal; Web is least.

Web Attacker

Malicious Site

Controls attacker.com, can obtain SSL cert. User visits attacker's site or runs attacker's app. Does not control the network.

Network Attacker

Interception

Passive: wireless eavesdropper. Active: evil router, DNS poisoning. Can intercept and modify traffic.

Malware Attacker

Most Lethal

Escapes browser isolation, runs under OS control. Browsers may contain exploitable bugs (remote code execution). Even bug-free browsers face XSS, SQLi, CSRF.

Threat Lethality

Least Lethal

→

Web Attacker

→

Network Attacker

→

Most Lethal - Malware Attacker

03 //

Same-Origin Policy

Origin Definition

An origin is a combination of URI scheme, hostname, and port number. Same-origin policy requires that requests to access data must be from the same origin.

SOP for DOM

Origin A can access origin B's DOM if A and B have the same (protocol, domain, port).

protocol://domain:port/path?params

SOP for Cookies

Generally based on (scheme, domain, path). Scheme is optional for backward compatibility.

Browser Sandbox

Goal

Safely execute JavaScript from remote websites. No direct file access; limited access to OS, network, browser data, and content from other origins. SOP restricts cross-origin DOM/cookie access.

Basic Execution Model

Each Window/Frame

1

Load - fetches content
2

Render - processes HTML/scripts; may involve images, subframes
3

Respond - user actions (onClick), rendering (onLoad), timing (setTimeout)

Content Sources

Browser content comes from many sources: <script src="...">, <iframe src="...">, <link rel="stylesheet" href="...">, Flash/plugins. Third-party scripts and iframes are common attack vectors.

04 //

Frame Security

Frames (rigid frameset) and iframes (floating inline) delegate screen area to content from another source. Each frame has an origin; the browser isolates frames by origin.

canScript(A,B)

Can Frame A execute a script that manipulates arbitrary/nontrivial DOM elements of Frame B?

canNavigate(A,B)

Can Frame A change the origin of content for Frame B?

readCookie(A,S)

Can Frame A read cookies from site S?

writeCookie(A,S)

Can Frame A write cookies for site S?

Browsing Context

Every browsing context (frame or web worker) has an origin, is isolated by SOP, may use postMessage for cross-origin communication, and can make network requests via XHR or tags.

05 //

Modern Structuring Mechanisms

HTML5 iframe Sandbox

Ensures iframe has unique origin, cannot execute JavaScript (unless allow-scripts), no form submission, disabled APIs, no plugins. Start with no permissions, then allow specific ones.

Sandbox Permissions

allow-scripts - JavaScript execution
allow-same-origin - retain origin (required for some features)
allow-forms - form submission
allow-popups - open new windows
allow-top-navigation - break out of frame

Don't Combine

allow-same-origin + allow-scripts together can bypass sandbox isolation - treat carefully.

Content Security Policy (CSP)

Goal

Prevent and limit damage of XSS. XSS bypasses SOP by tricking a site into delivering malicious code. CSP restricts resource loading to a whitelist via Content-Security-Policy HTTP header.

CSP Approach

Prohibits inline scripts, inline event handlers, javascript: URLs
Disables eval(), new Function()
Whitelist instructs browser to only execute/render resources from specified sources

CSP Directives

Directive	Purpose
`script-src`	Origins for loading scripts
`connect-src`	Origins for XHR, WebSockets, EventSource
`frame-src`	Origins for embedded frames
`img-src`	Origins for images
`style-src`	Origins for stylesheets
`default-src`	Fallback for unspecified directives

CSP Source Lists

'self'

Current origin only (not subdomains)

'unsafe-inline'

Allows inline JavaScript/CSS - weakens XSS protection

'unsafe-eval'

Allows eval(), new Function() - weakens XSS protection

SubResource Integrity (SRI)

Protect against modified CDN content (DNS poisoning, hostile server). Page author specifies a hash of the resource; browser verifies integrity before loading.

HTML5 Web Workers

Run in isolated thread, loaded from separate file. Same origin as creating frame, no DOM. Communicate via postMessage. Helps with performance and isolation.

var worker = new Worker('task.js'); worker.postMessage('Hello'); worker.addEventListener('message', function(e) { console.log(e.data); });

06 //

Cookies & SOP

Set-Cookie Attributes

Cookie Scope & Security

                domain, path
              

When to send - default: domain and path of setting URL

                Secure
              

Only send over HTTPS

                HttpOnly
              

Not readable by document.cookie - weak XSS defense

                SameSite
              

lax | strict - weak CSRF defense

Scope Rules

login.site.com can set cookies for .site.com but not for another site or TLD. Domain: any domain-suffix of URL hostname, except TLD. Path: can be set to anything.

Client-Side: document.cookie

Read: document.cookie - returns all cookies for current (protocol, domain, path)
Write: document.cookie = "name=value; expires=..."
Delete: Set expires=Thu, 01-Jan-70
HttpOnly cookies are NOT included in document.cookie

Cookie Protocol Problems

Server is blind - receives only Cookie: NAME=VALUE, no attributes (secure, HttpOnly), no domain info. No integrity - user can edit/delete; network attacker can inject Set-Cookie over HTTP to overwrite secure cookies. Path separation is for efficiency, not security - x.com/A can still iframe x.com/B and read its cookies.

Cookie Integrity - Cryptographic Checksums

Use server-side secret key k. Set: MACsign(k, SID || name || value) → T. Verify: MACverify(k, SID || name || value, T). Example: ASP.NET HttpSecureCookie.Encode/Decode with MachineKey.

07 //

Session Management

A session is a sequence of requests/responses from one browser to one or more sites. Session management: authorize once; all subsequent requests tied to user. Without it, users would constantly re-authenticate.

Storing Session Tokens

Set-Cookie: SessionToken=fduhye63sfdb

URL Embed

https://site.com/checkout?SessionToken=kh7y3b

Hidden Form

<input type="hidden" name="sessionid" value="kh7y3b">

Best: combination of all three for redundancy.

Logout & Token Revocation

Proper Logout

1. Delete SessionToken from client. 2. Mark session token as expired/revoked on server. Many sites do 1 but not 2 - risky, especially when falling back to HTTP after login.

Session Hijacking

Attacker sniffs a legitimate session ID and impersonates the victim. Defense: HTTPS, HttpOnly, Secure, SameSite, short expiry.

Predictable Tokens

Beware of weak/predictable session IDs. Counter-based or weak MAC tokens can expose secrets - use cryptographically random tokens with sufficient entropy.

HTTP Referer Header

Shows the page you came from. Problem: leaks URL/session token to third parties. Solution: <a rel="noreferrer" href="..."> or Referer suppression. Not sent when HTTP refers to HTTP (mixed content rules).

08 //

Summary & Key Takeaways

Isolation & SOP

Origin

protocol + hostname + port. Same origin = full DOM/cookie access.

Sandbox

No direct file/OS access. SOP limits cross-origin access.

Frames

canScript, canNavigate, readCookie, writeCookie - isolation by origin.

Defense Mechanisms

CSP

Whitelist script/style/frame sources. Blocks inline scripts, eval. Mitigates XSS.

iframe Sandbox

Unique origin, no scripts/forms/plugins by default. Add allow-* as needed.

SRI

Hash in integrity attribute - browser verifies CDN content before execution.

Cookies & Sessions

Cookies have no integrity - server is blind to attributes; network attacker can overwrite. Use HttpOnly, Secure, SameSite, and cryptographic signing (MAC) for sensitive values. Session tokens must be unpredictable; revoke on logout server-side.