Vitaly Shmatikov

1
Web Browser Security
CS 380S

• Vitaly Shmatikov
• (most slides from the Stanford Web security group)

2
Reading Assignment

• Barth et al. Robust Defenses for Cross-Site
  Request Forgery.
• Jackson and Barth. Beware of Finer-Grained
  Origins.
• Jackson et al. Transaction Generators Root Kits
  for Web.
• Optional (but very interesting) Barth et al.
  Securing Frame Communication in Browsers.

3
Browser Security Policy

• Same-origin policy
• alert(frames0.document.cookie)
• Library import
• Data export

4
Document Object Model (DOM)

• HTML page is structured data DOM provides
  representation of this hierarchy
• Can be manipulated with JavaScript to change Web
  page shown to the user
• For example, write document.alinkColor,
  document.URL, document.forms , document.links
  , document.anchors
• Also Browser Object Model (BOM)
• Window, Document, Frames, History, Location,
  Navigator (type and version of browser)

5
Browser and Document Structure
W3C standard differs from models supported in
existing browsers
6
JavaScript Security Model

• Same-origin policy
• Frame can only read properties of documents and
  windows from same place server, protocol, port
• Does not apply to scripts loaded in enclosing
  frame from arbitrary site
• This script runs as if it were loaded from the
  site that provided the page!

src"http//www.example.com/scripts/somescript.js"

7
Components of Security Policy

• Frame-Frame relationships
• 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?
• Frame-principal relationships
• readCookie(A,S), writeCookie(A,S)
• Can Frame A read/write cookies from site S?
• Security indicator (lock icon)
• securityIndicator(W) - is it displayed for window
  W?

8
Common Misunderstanding

• Often simply stated as same-origin policy
• This usually just refers to the canScript
  relation
• Full policy of current browsers is complex
• Evolved via penetrate-and-patch
• Different features evolved slightly different
  policies
• Common scripting and cookie policies
• canScript considers scheme, host, and port
• canReadCookie considers scheme, host, and path
• canWriteCookie considers host

9
Cross-Frame Scripting

• canScript(A,B) - only if Origin(A) Origin(B)
• Basic same-origin policy, where origin is the
  scheme, host and port from which the frame was
  loaded
• What about frame content?
• Some browsers allow any frame to navigate any
  other frame
• See Securing Frame Communication for details

10
Guninski Attack
awglogin
If bad frame can navigate good frame, attacker
gets password!
11
Gadget Hijacking
top.frames1.location "http/www.attacker.com/.
.. top.frames2.location "http/www.attacker.
com/... ...
12
Gadget Hijacking
13
Finer-Grained Origins

• Some browser features grant privileges to a
  subset of documents in an origin
• Cookie paths
• Mixed content
• For example, documents with invalid certificates
  mixed with documents with valid certificates
• Any less trusted document can inject an
  arbitrary script into a more trusted one (why?)
• Gain the same privileges as the most trusted
  document in the same origin!

14
Origin Contamination
15
Mixed Content Issues

• All browsers fail to account for canScript
• One fix Safelock browser extension revokes the
  ability to dispay the lock icon from all
  documents in the same origin as an insecure
  document
• Lots of other bugs
• Fail to detect insecure SWF movies (IE, Firefox)
• Navigation forgets mixed content (Firefox)
• Firefox architecture make detection difficult

16
Example of a Vulnerability
Chase used a SWF movie served over HTTP to
perform authentication on the banking login page
active network attacker can steal password!
17
Problems with Data Export

• Abusing users IP address
• Can issue commands to servers inside firewall
• Reading browser state
• Can issue requests with cookies attached
• Writing browser state
• Can issue requests that cause cookies to be
  overwritten

18
XSRF Cross-Site Request Forgery
19
Login XSRF
20
Inline Gadgets
21
Using Login XSRF for XSS
22
XSRF vs. XSS

• Cross-site scripting
• User trusts a badly implemented website
• Attacker injects a script into the trusted
  website
• Users browser executes attackers script
• Cross-site request forgery
• A badly implemented website trusts the user
• Attacker tricks users browser into issuing
  requests
• Website executes attackers requests

23
XSRF Defenses

• Secret validation token
• Referer validation
• Custom HTTP header

Referer http//www.facebook.com/home.php
X-Requested-By XMLHttpRequest
24
Secret, Random Validation Token

• Hash of user ID
• Can be forged by attacker
• Session ID
• If attacker has access to HTML of the Web page
  (how?), can learn session ID and hijack the
  session
• Session-independent nonce Trac
• Can be overwritten by subdomains, network
  attackers
• Need to bind session ID to the token
• CSRFx, CSRFGuard - Manage state table at the
  server
• HMAC (keyed hash) of session ID no extra state!

25
NoForge

• Binds token to session ID using server-side state
• Requires a session before token is validated
• Does not defend against login XSRF
• Parses HTML and appends token to hyperlinks
• Does not distinguish between hyperlinks back to
  the application and external hyperlinks
• Remote site gets users XSRF token, can attack
  referer
• except for dynamically created HTML (why?)
• Gmail, Flickr, Digg use JavaScript to generate
  forms that need XSRF protection

26
Referer Validation
?
Referer http//www.facebook.com/home.php
?
Referer http//www.evil.com/attack.html
?
Referer

• Lenient referer checking header is optional
• Strict referer checking header is required

27
Why Not Always Strict Checking?

• Reasons to suppress referer header
• Network stripping by the organization
• For example, http//intranet.corp.apple.com/
  projects/iphone/competitors.html
• Network stripping by local machine
• Stripped by browser for HTTPS ? HTTP transitions
• User preference in browser
• Buggy user agents
• Web applications cant afford to block these
  users
• Feasible over HTTPS (header rarely suppressed)
• Logins typically use HTTPS helps against login
  XSRF!

28
XSRF with Lenient Referer Checking

• http//www.attacker.com
• redirects to
• ftp//www.attacker.com/index.html
• javascript" / CSRF / "
• datatext/html, / CSRF /

common browsers dont send referer header
29
Custom Header

• XMLHttpRequest is for same-origin requests
• Browser prevents sites from sending custom HTTP
  headers to other sites, but can send to
  themselves
• Can use setRequestHeader within origin
• Limitations on data export format
• No setRequestHeader equivalent
• XHR 2 has a whitelist for cross-site requests
• Issue POST requests via AJAX. For example
• No secrets required

X-Requested-By XMLHttpRequest
30
Ideal XSRF Defense

• Does not break existing sites
• Easy to use
• Allows legitimate cross-site requests
• Reveals minimum amount of information
• No secrets to leak
• Standardized

31
Origin Header
Barth et al.

• Add origin header to each POST request
• Identifies only the principal that initiated the
  request (scheme, host, port of active documents
  URL)
• Does not identify path or query (unlike referer
  header)
• Simply following a hyperlink reveals nothing
  (why?)
• No need to manage secret token state
• Simple firewall rule for subdomains, affiliates
• SecRule REQUEST_HEADERSHost !www\.example\.com(
  \d)? deny,status403
• SecRule REQUEST_METHOD POST chain,deny,status40
  3
• SecRule REQUEST_HEADERSOrigin !(https?//www\.ex
  ample\.com(\d)?)?
• Supported by XHR2, JSONRequest, expected in IE8s
  XDomainRequest

32
Other Identity Misbinding Attacks

• Users browser logs into website, but site
  associates session with the attacker
• Login XSRF is one example of this
• OpenID
• PHP cookieless authentication
• Secure cookies

33
OpenID
34
PHP Cookieless Authentication
35
Secure Cookies
Overwrites or sets cookie
36
Transaction Generator Problem

• Malware installed as browser
• extension
• Once user is logged in, can
• Corrupt user requests
• Issue unauthorized requests

authenticated channel
Bank

Attacker
37
Transaction Confirmation
Authentication agent
Application environment
Remote server
User
Transaction details D
Confirmation (trusted path)
?
?
HMACK (D)

• Application environment cant MAC fake
  transaction
• Server puts transaction ID inside D to foil
  replay