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

Originally, much of the security action in web applications was on the server.
  So far in this class, 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.

This lecture: isolation between sites in a web brwoser.
  But there's increasingly more happening in the web browsers as well.
  Modern web applications: HTML, CSS, Javascript, Flash, Native Client, ..
  Lower latency interactions: no need to wait for server round-trip.
  Overall plan is called the "same-origin policy".
    One of the best descriptions is in "The Tangled Web" (today's reading).

How did this design come about?
  Incremental design/development: no single coherent design.
    Noone expected web browsers to be used in the ways they are today.
    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.

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.
  Web browsers continuously change.
    New mechanisms have come out since "The Tangled Web".
    But mostly adding onto the existing design, rather than replacing it.

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 implementation bugs (e.g., buffer overflows).
    Will try to solve separately with wide variety of techniques.

Security goal for web browsers: isolate different web sites from each other.
  Vague goal: a malicious web site shouldn't interfere with other sites.
    Example: web sites should not be able to tamper with each other.
      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..
    Example: user should know what site they're interacting with.
      Needed if user is relying on page contents, or enters confidential data,
                        or performs some important operation (e.g., xfer money).
      Phishing attacks often try to mislead the user / violate UI security.
      Note: identifying site is meaningless if sites can tamper w/ each other.
  Difficult: web sites must be able interact with each other, in certain ways.
    Fundamental: sites link to other sites.
    Can include images from other sites.
    Mash-ups: Google Maps + craigslist, Facebook "Like" button,
              ads, Login with Google, ...
    All sites potentially "running" in the same web browser on user's machine.

What does the browser have to worry about?
  The actor in a web browser is a document loaded in a window.
    Moral equivalent in Unix: a program running in a process.
    Most interesting is an HTML document, but can have others (e.g., PDF).
  What can a document "do"?
    Link to other pages; user might click on a link: <a href="someurl">
    Include image files, style sheet files, etc: <img src="someurl">
    Load another document in a frame: <iframe src="someurl">
    Run Javascript code in the web browser: <script>.. code ..</script>
    Include Javascript code by URL: <script src="someurl">
  A document running Javascript code can perform many more operations.
    Access parts of the document for the current page.
    Access other windows and frames, and their documents.
    Navigate existing windows, frames.
    Open new windows, frames.
    Send requests over the network.
    ...

Aside: running Javascript in the browser.
  How does Javascript interact with a web page?
    HTML elements -> DOM nodes organized in a tree.
    JS code in <SCRIPT> tags, event handlers (onClick) on DOM nodes, etc.
    DOM nodes are objects that can be manipulated by Javascript.
    Global objects (window, document, XMLHttpRequest) allow add'l operations.
    HTML elements / DOM nodes can invoke Javascript via event handlers.
    HTML frames allow documents from multiple sites to co-exist in one window.
    JS issues HTTP requests using XMLHttpRequest or by creating DOM nodes.
    You will learn much more about Javascript in lab 5.
  How does the browser isolate Javascript code?
    Sandbox code: interpose on all interactions with resources.
      The browser is providing the interpreter that runs Javascript code.
    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!
    Controlled access to resources: decide what operations can be performed.
      Based on the same-origin policy.
    Some bugs arise in sandboxing code, but more interesting are "design" bugs.
      Issues with the same-origin policy that is not an implementation bug.
      E.g., designers did not think through all implications of some API.
      Moral equivalent of "protocol bugs" that Bellovin talked about in TCP/IP.
      Hard to fix without coming up with a new design, breaking existing sites.

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)
  Caveat: IE does not include the port number in the "origin".
  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.
    Requires assigning an origin to every resource.
    Does not specify how different origins should interact if necessary.
    Invented "after the fact", so there are a number of exceptions.

  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., can force victim into attacker's gmail account.
        Attacker will be able to read victim's sent emails.
      Similar with the 6.858 web site: can force victim into attacker's account.
        Attacker will be able to download victim's lab submissions.

    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.
        [ Ref: http://publicsuffix.org/ ]
      Non-secure cookie can sometimes override existing secure cookie.

  Some resources have a bunch of exceptions: HTTP responses.
    Accessible almost exclusively 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.
        See "The Tangled Web" chapter 11, page 182 for a CSS-based example.
      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.
      Same-origin policy inherently relies on DNS for security!
    Conversely, creating hostname in a domain pointing to an IP implies trust.
      That IP can serve up content in that domain's origin.
      localhost.foo.com problem.

    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.

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.
    Sometimes called "JSONP".

  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: IP-based instead of DNS-name-based.
  Silverlight.
  ...

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!

  HTTP header injection from XMLHttpRequest.  (The Tangled Web page 147)
    Javascript can ask browser to add extra headers.
    What if it asks to add a header called "Content-Length" with value "0"?
      Server might interpret this as meaning there's no payload to request.
      Will interpret subsequent bytes as the next request!
    What if it asks to add a header called "Content-Length: 0\r\n", value "x"?
      Browser might send "Content-Length: 0\r\n: x\r\n"?
    Javascript can also ask for a particluar method name (e.g., POST vs GET).
      What if it asks for method "GET / HTTP/1.0\r\nHost: www.foo.com\r\n"?
      Server might interpret this as a request for another virtual host!
    Unambiguous encoding is critical!  Build reliable escaping/encoding!

  URL parsing.  (The Tangled Web page 154)
    Flash had a slightly different URL parser than the browser.
      Suppose the URL was http://example.com:80@foo.com/
      Flash would compute the origin as "example.com"
      Browser would compute the origin as "foo.com"
    Bad idea: complex parsing rules just to determine the principal.
    Bad idea: re-implementing complex parsing code.

  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.
    UTF-8 vs ISO-8859-1.

  Lessons:
    Be explicit about security-relevant aspects.
    Make it easy to parse out the security-relevant parameters.
    Avoid ambiguity in encoding rules, corner cases.

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

Surprising interactions between features:
  Cookie "secure" flag not quite the same as protocol in origin.
  XMLHttpRequest.getResponseHeader() vs httponly cookies.
  Somewhat-trusted file:// URLs and untrusted downloaded files. (pg. 160)

What's changed since this book 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?).