Avishai Wool Slides credit: Dan Boneh, John Mitchell Introduction to Information Security 0368-3065, Spring 2017 Lecture 12: Browser Security, Sessions Avishai Wool Slides credit: Dan Boneh, John Mitchell

HTTPS in the Browser

The lock icon: SSL indicator Intended goal: Provide user with identity of page origin Indicate to user that page contents were not viewed or modified by a network attacker In reality: Origin ID is not always helpful example: Stanford HR is hosted at BenefitsCenter.com Many other problems (next few slides) Network attacker: controls routers, DNS; can inject, delete, and modify packets

When is the (basic) lock icon displayed All elements on the page fetched using HTTPS (with some exceptions) For all elements: HTTPS cert issued by a CA trusted by browser HTTPS cert is valid (e.g. not expired) CommonName in cert matches domain in URL

The lock UI: Extended Validation (EV) Certs Green background or text in browser URL Harder to obtain than regular certs requires human lawyer at CA to approve cert request Designed for banks and large e-commerce sites

A general UI attack: picture-in-picture Both inner and outer windows are focused Trained users are more likely to fall victim to this [JSTB’07]

HTTPS and login pages: the bad way Users often land on login page over HTTP: Type site’s HTTP URL into address bar, or Google links to the HTTP page User has no way to tell that his password is sent over HTTPS to site. Also has no way to tell that page wasn’t modified enroute (e.g. change form action). Note the confusing lock next to “LOGIN” that suggests this is HTTPS. View source: <form method="post" action="https://onlineservices.wachovia.com/..."

HTTPS and login pages: guidelines General guideline: never show a login screen via http Response to http://login.site.com should be Redirect: https://login.site.com

Problems with HTTPS and the Lock Icon

Attack: prevent the upgrade (ssl_strip) [Moxie’08] HTTP  HTTPS upgrade Common use pattern: browse site over HTTP; move to HTTPS for checkout connect to bank over HTTP; move to HTTPS for login Attack: prevent the upgrade (ssl_strip) [Moxie’08] In pages returning from web server, attacker modifies: <a href=https://…>  <a href=http://…> Location: https://...  Location: http://... (redirect) <form action=https://… >  <form action=http://…> attacker web server SSL HTTP ssl_strip: prevents browser from upgrading, but does the SSL upgrade when communicating with the server. Server has no idea this is taking place.

Tricks and Details Tricks: drop-in a clever fav icon (older browsers) Erase existing session and force user to login: ssl_strip injects “Set-cookie” headers to delete existing session cookies in browser. 

Semantic attacks on certs International domains: xyz.cn Rendered using international character set Observation: Chinese character set contains chars that look like “/” and “?” and “.” and “=” Attack: buy domain cert for *.badguy.cn setup domain called: www.bank.com/accounts/login.php?q=me.baguy.cn note: single cert *.badguy.cn works for all sites Extended validation (EV) certs may help defeat this

[Moxie’08]

Mixed Content: HTTP and HTTPS Page loads over HTTPS, but contains content over HTTP (e.g. <script src=“http://.../script.js> ) Active network attacker can hijack session Modifies script en-route to browser A better way to embed content (from the same site): <script src=“//.../script.js> served over the same protocol as embedding page Can use for content served over HTTP or HTTPS

Mixed Content: HTTP and HTTPS IE7: Chrome: No SSL lock in address bar: 15

Network traffic reveals length of HTTPS packets Peeking through SSL Network traffic reveals length of HTTPS packets TLS supports up to 256 bytes of padding AJAX-rich pages have lots and lots of interactions with the server These interactions expose specific internal state of the page BAM! Chen, Wang, Wang, Zhang, 2010

Peeking through SSL: an example Vulnerabilities in an online tax application No easy fix. Can also be used to ID Tor traffic 17

Isolation

Frame and iFrame A browser window may contain frames from different sources Frame: rigid division as part of frameset iFrame: floating inline frame iFrame example Why use frames? Delegate screen area to content from another source E.g., our course questionnaire page uses Google Forms Browser provides isolation based on frames Parent may work even if frame is broken <iframe src="http://othersite.com/inner.html" width=450 height=100> If you can see this, your browser doesn't understand IFRAME. </iframe>

Same Origin Policy (SOP) Each frame of a page has an origin Origin = protocol://host:port Frame can access its own origin Network access, Read/write DOM, Storage (cookies) Frame cannot access data associated with a different origin (but it can still cause the browser to fetch it, e.g., via IMG) A A B A B

SOP examples URL: "http://www.example.com/dir/page.html". Compared URL Outcome Reason http://www.example.com/dir/page2.html Success Same protocol, host and port http://www.example.com/dir2/other.html http://www.example.com:81/dir/other.html Failure Same protocol and host but different port https://www.example.com/dir/other.html Different protocol http://en.example.com/dir/other.html Different host http://example.com/dir/other.html Different host (exact match required) http://v2.www.example.com/dir/other.html http://www.example.com:80/dir/other.html Depends Port explicit. Depends on implementation in browser. Source: wikipedia

Inter-frame communication policy? Sibling Frame Bust Child Descendant 22

Legacy Browser Behavior Policy IE 6 (default) Permissive IE 6 (option) Child IE7 (no Flash) Descendant IE7 (with Flash) Firefox 2 Window Safari 3 Opera 9 HTML 5 23

JavaScript is not subject to SOP “VeriSign Secured Seal” : <script src="https://seal.verisign.com/getseal?host_name=a.com"></script> VeriSign Website analytics: <script src=“http://site-analytics.com/trackvisit.js?account=..."></script> Script runs in same frame as the HTML that invokes it. Thus: Script has privileges of importing page, NOT source server. Can script other pages in this origin, load more scripts Other forms of importing: Website listing ways to bypass SOP

Session Management

Session mgmt: authorize user once; Sessions A sequence of requests and responses from one browser to one (or more) sites Session can be long (e.g. Gmail) or short without session mgmt: users would have to constantly re-authenticate Session mgmt: authorize user once; All subsequent requests are tied to user

Pre-history: HTTP auth HTTP request: GET /index.html HTTP response contains: WWW-Authenticate: Basic realm="Password Required“ Browsers sends hashed password on all subsequent HTTP requests: Authorization: Basic ZGFddfibzsdfgkjheczI1NXRleHQ=

HTTP auth problems Hardly used in commercial sites: User cannot log out other than by closing browser What if user has multiple accounts? multiple users on same machine? Site cannot customize password dialog Confusing dialog to users Easily spoofed

Session tokens Browser web site check credentials (crypto) Validate GET /index.html set anonymous session token GET /books.html anonymous session token check credentials (crypto) POST /do-login Username & password elevate to a logged-in session token Validate token: check that it belongs to an active session that has not been logged out or timed out. POST /checkout logged-in session token Validate token

Storing session tokens Lots of options (but none are perfect) Browser cookie: Set-Cookie: SessionToken=kh7y3b Embed in all URL links: https://site.com/checkout ? SessionToken=kh7y3b In a hidden form field: <input type=“hidden” name=“sessionid” value=“kh7y3b”>

Storing session tokens: problems Browser cookie: browser sends cookie with every request, even when it should not (CSRF) Embed in all URL links: token leaks via HTTP Referer header In a hidden form field: does not work for long-lived sessions Best answer: a combination of all of the above. (or if user posts URL in a public blog)

The HTTP referer header Referer leaks URL session token to 3rd parties Referer supression: not sent when HTTPS site refers to an HTTP site in HTML5: <a rel=”noreferrer” href=www.example.com>

The Logout Process Web sites must provide a logout function: Functionality: let user to login as different user Security: prevent others from abusing account What happens during logout: 1. Delete SessionToken from client 2. Mark session token as expired on server Problem: many web sites do (1) but not (2) !! ⇒ Especially risky for sites who fall back to HTTP after login

Session hijacking

Session hijacking Attacker waits for user to login then attacker steals user’s Session Token and “hijacks” session ⇒ attacker can issue arbitrary requests on behalf of user Example: FireSheep [2010] Firefox extension that hijacks Facebook session tokens over WiFi. Solution: HTTPS after login

Beware: Predictable tokens Example 1: counter ⇒ user logs in, gets counter value, can view sessions of other users Example 2: weak MAC. token = { userid, MACk(userid) } Weak MAC exposes k from few cookies. Apache Tomcat: generateSessionId() Returns random session ID [server retrieves client state based on sess-id] Don’t generate your own. Use built in procedures: ASP, Tomcat, JServ

Session tokens must be unpredictable to attacker To generate: use underlying framework (e.g. ASP, Tomcat, Rails) Rails: token = MD5( current time, random nonce ) Don’t generate your own. Use built in procedures: ASP, Tomcat, JServ

Beware: Session token theft Example 1: login over HTTPS, but subsequent HTTP Enables cookie theft at wireless Café (e.g. Firesheep) Other ways network attacker can steal token: Site has mixed HTTPS/HTTP pages ⇒ token sent over HTTP Man-in-the-middle attacks on SSL Example 2: Cross Site Scripting (XSS) exploits Amplified by poor logout procedures: Logout must invalidate token on server

Mitigating SessionToken theft Idea: binding SessionToken to client’s computer Client IP addr: makes it harder to use token at another machine But honest client may change IP addr during session client will be logged out for no reason. Client user agent: weak defense against theft, but doesn’t hurt. (“user agent” = browser type + version) Can also embed agent’s timezone.

Session fixation attacks Suppose attacker can set the user’s session token: For URL tokens, trick user into clicking on URL For cookie tokens, set using XSS exploits Attack: (say, using URL tokens) Attacker gets anonymous session token for site.com Sends URL to user with attacker’s session token User clicks on URL and logs into site.com this elevates attacker’s token to logged-in token Attacker uses elevated token to hijack user’s session.

Session fixation: lesson When elevating user from anonymous to logged-in: always issue a new session token After login, token changes to value unknown to attacker ⇒ Attacker’s token is not elevated. Problems with new SessionToken after every request: the back button (but can be dealt with with proper handling of replays)

Always assume cookie data retrieved from client is adversarial Summary Always assume cookie data retrieved from client is adversarial Session tokens are split across multiple client state mechanisms: Cookies, hidden form fields, URL parameters Cookies by themselves are insecure (CSRF, cookie overwrite) Session tokens must be unpredictable and resist theft by network attacker Ensure logout invalidates session on server

THE END