1. Avishai Wool Slides credit: Dan Boneh, John Mitchell
Introduction to Information Security , Spring Lecture 12: Browser Security, Sessions
Avishai Wool Slides credit: Dan Boneh, John Mitchell

2. HTTPS in the Browser

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

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

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

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

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

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

9. Problems with HTTPS and the Lock Icon

10. 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=  <a href=
Location:  Location: (redirect)
<form action= >  <form action=
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.

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

12. 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:
note: single cert *.badguy.cn works for all sites
Extended validation (EV) certs may help defeat this

13. [Moxie’08]

14. Mixed Content: HTTP and HTTPS
Page loads over HTTPS, but contains content over HTTP
(e.g. <script src=“ )
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

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

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

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

18. Isolation

19. 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=" width=450 height=100>
If you can see this, your browser doesn't understand IFRAME.
</iframe>

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

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

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

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

24. JavaScript is not subject to SOP
“VeriSign Secured Seal” :
<script src="
VeriSign
Website analytics:
<script src=“
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

25. Session Management

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

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

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

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

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

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

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

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

34. Session hijacking

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

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

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

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

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

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

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

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

43. THE END