===
Web security policies
===

Previous parts were mostly concerned with the server. Let's take a look at the browser.

What exactly does a browser do? - HTTP, SSL, FTP, HTML, CSS, Javascript, plugins (flash, silverlight, ...) etc.

Browser does lots of things, and there are many different browsers.

The web has no coherent design, it all came incrementally: Race to add new features, 
strive to be tolernant with sloppy websites -> bad for security.

What are the securiy goals in this context? What is the threat model?
    
Threat model:
    Adversary controls his/her website
    Adversary can cause victim to visit his website (links, ads)
    Cannot intercept/inject packets (we'll cover HTTPS later)
    Server and browser don't have bugs (but website may well have!)

Goal:
    Isolate different websites from each other. Attacker shouldn't be able to interfere with other
    websites.

Why is this difficult?
    We want to allow interaction between websites:
        Links, frames (embedding), mashups
    Many pages might be running at the same time in the browser.
    Javascript can access other frames, open new windows, make requests, navigate etc.

Why do we run javascript in the browser then?
    Make websites more reactive, saves round-trip, allow more complex behaviour.

So what happens when the browser loads a page?
    Resolve hostname (DNS)
    Send request to server
    Render the response (Rendering Engines: webkit, gecko, blink)
    Start executing javascript (happens already while rendering)

How does Javascript work?
    Embedded (<script> tags), external resource (<script src="http://...">, event handlers (onclick="")
    Javascript can read and modify DOM (document object model), access some
    global objects (window, XMLHttpRequest), submit forms, set/read cookies, etc.

So how do we secure this? - Same origin policy
    Origin is tuple of (protocol, host, port) (just protocol and host in IE!)
    Example: https://www.mit.edu => (https,www.mit.edu,80)

    Javascript runs "sandboxed" in the origin of the http document that loaded it
    Source of script doesn't matter, only origin of http document!
    DOM access determined by SOP
    Possible to set document.domain to higher-level domain (with hardcoded exceptions like .com, .co.uk etc.)

What about cookies?
    Cookies keep state, because HTTP is stateless
    Often used for authentication
    They have a slightly different isolation logic (like origins, but not quite)
Who can set a cookie?
    Cookies can be set for domain and path
    i.e. http://scripts.mit.edu can set for scripts.mit.edu or *.mit.edu, but not *.com
    Can also set for specific path, ie. scripts.mit.edu/~helfer/ (don't rely on for security!)

Who can get the cookie?
    Browser sends cookie along with every request where domain and path match.
    Javascript can access cookies that match origin (and are not httponly). "secure" flag also matters

What network resources can a page access?
    Only same-origin resources, with a few exceptions:
        images, scripts, css, plugin content
        Can't inspect response, but usually possible to infer information

"Special origins"
    Origin inheritance:
        sometimes origin comes from creator, sometimes given by target, sometimes inacessible origin
    about:blank
    about:config
    javascript:...
    data:...
    blob:...

Frames can share one window:
    No origin for pixels => clickjacking by overlaying transparent frame

Cross-origin frame communication:
    Historically some insecure ad-hoc methods, JSONP, hash fragment
    now CORS, postMessage


Different security policies for plugin content:
    crossdomain.xml for flash

The issue of ambiguous protocols:
    Response splitting, HTTP header injection
    URL parsing (many different implementations of parser)
    HTML parsing (very difficult to sanitize user input)
    Content sniffing (jpg might be misinterpeted as html and run in the same origin!)

===
Web application defenses
===
Problem:
    Websites are dynamic, take user input in forms, store in DB, incorporate user content in their page

Common attacks:
    XSS (cross site scripting, i.e. injecting javascript into a page)
    CSRF (cross site request forgery, i.e. 'faking' a request that has side effects)
    Cookie injection (causing browser to send attacker's cookie along with some request)
    SQL injection

XSS:
    Reflection attack:
        http://foo.bar.com/name=<script>alert(1)</script>
        Dangerous even if user wouldn't enter the url. Some script running on attackers site 
        can redirect you to that url and run code in foo.bar.com's origin!

    Persistent attack:
        Gets written to db/file and run every time page is loaded (eg. myspace worm)

    Defenses:
        Browser XSS defenses:
            Check if fragments of input are in page output. Only works for reflection, incomplete.


CSRF:
    http://buysomething.com?item_id=1253412&ship_to=attacker
    Can send this GET request from any origin! Same goes for POST
    
    Defenses:
        Include a token in forms, check for valid token on submit (store in session or cookie)
        Attacker must not be able to obtain/forge token

Session fixation:
    Cause the user to log into attackers session. Attacker can see what user did (i.e. send emails)
    Make sure you don't share domain with untrusted third parties (ie. all of mit.edu)
    Also possible if login page has no CSRF protecton (page logs attacker in, sets cookie)

SQL injection:
    $query = "SELECT * FROM users WHERE username=" + $_GET['username']
    http://foo.bar.com/?username=' or 1 or ''='
    
    Defense:
        Always properly escape data (SQL libraries provide functions like mysql_real_escape_string)
        Django: use ORM, developer doesn't actually write queries
    
Clickjacking:
    Invisible frame on top of visible frame
    Defense:
        Don't allow embedding as frame (X-Frame-Options: deny)
        For pages that have to be embedded: ask for user confirmation on non-embeddable page

Directory traversal:
    open("/var/www/foobar/"+filename)
    http://foo.bar.com/../../etc/passwd
    Defense:
        Properly encode

===
HTTPS
===
Essentially HTTP on top of SSL

Send data over encrypted channel to ensure confidentiality
Uses public key cryptography to establish secure session (SSL handshake)
Exchange a symmetric key (for speed) after establishing secure connection with asymmetric crypto

  Encryption provides data secrecy, use message authentication integrity.
  Message authentication code (MAC) with symmetric keys can provide integrity.
    Look up HMAC if you're interested in more details.
  Can use public-key crypto to sign and verify, almost the opposite:
    Use secret key to generate signature (compute D_SK)
    Use public key to check signature (compute E_PK)

How do we establish a secure connection?
    Must know that we're talking to the right server
    If computers already know eachothers public keys:
        No problem, just connect
    If computers don't know eachoters public keys (usually the case for HTTPS):
        Use "Certificate Authorities" that sign server's public key
        Browsers have a list of certificate authorities that they trust

What can go wrong?
    Crypto:
        Some attacks, but nothing earth shattering.
        Crypto is usually not the weakest part

    Authenticating the server:
        Adversary can obtain certificate in someone else's name
        Security depends on weakest of over 100 CAs (lists shipped with browser, BIG problem)
        CA compromises happen

        What if a certificate is compromised?
            Certificate revocation lists (soft-fail, thus susceptible to DNS)

    Mixed content (HTTP and HTTPS)
        Adversary can tamper with HTTP responses. If scripts or plugin content are
        included in same origin over HTTP, they have full access.
        
    Cookie confidentiality:
        HTTPS cookies can be sent over HTTP unless marked with "secure" flag

    Users not checking "lock icon", clicking away warnings
        Yeah, it's that simple...

    Login form on HTTP page:
        Even if login form target is HTTPS, attacker can just inject code into HTTP login page
        and collect credentials when they're entered.

Possible solutions:
    ForceHTTPS: (stored bit in a cookie)
        Prohibit mixed content
        Prohibit user from overriding certificate errors
        Mark all HTTPS cookies as secure
        

        Difficulties:
            Bootstrapping:
                use DNSSEC
                embed in url
                incldue in certificate
            Potential privacy leak
            Use for denial of service attack