CS 142 Winter 2009
Session Management
Dan Boneh
Sessions
A sequence of requests and responses from
one browser to one (or more) sites
Session can be long (Gmail - two weeks)
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 /[Link]
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?
What if multiple users on same computer?
Site cannot customize password dialog
Confusing dialog to users
Easily spoofed
Session tokens
Browser Web Site
GET /[Link]
set anonymous session token
GET /[Link]
anonymous session token
POST /do-login check
Username & password credentials
elevate to a logged-in session token (CS155)
POST /checkout
logged-in session token Validate
token
Storing session tokens:
Lots of options (but none are perfect)
• Browser cookie:
Set-Cookie: SessionToken=fduhye63sfdb
• Embedd in all URL links:
[Link] ? SessionToken=kh7y3b
• In a hidden form field:
<input type=“hidden” name=“sessionid”
value=“kh7y3b”>
• [Link] DOM property
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: short sessions only
Best answer: a combination of all of the above.
why? next lecture.
The HTTP referer header
Referer leaks URL session token to 3rd parties
SESSION HIJACKING
Attacker waits for user to login;
then attacker obtains user’s Session Token
and “hijacks” session
1. Predictable tokens
Example: counter (Verizon Wireless)
user logs in, gets counter value, can view sessions of
other users
Example: weak MAC (WSJ)
token = {userid, MACk(userid) }
Weak MAC exposes k from few cookies.
Session
Apache tokens must
Tomcat: be unpredicatble to attacker:
generateSessionID()
Use underlying
MD5(PRG) framework.
… but weak PRG [GM’05].
Predictable SessionID’s
Rails: token = MD5( current time, random nonce )
2. Cookie theft
Example 1: login over SSL, but subsequent HTTP
What happens as wireless Café ?
Other reasons why session token sent in the clear:
HTTPS/HTTP mixed content pages at site
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
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)
1. Attacker gets anonymous session token for [Link]
2. Sends URL to user with attacker’s session token
3. User clicks on URL and logs into [Link]
this elevates attacker’s token to logged-in token
4. 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
• Once user logs in, token changes to value
unknown to attacker.
Attacker’s token is not elevated.
Generating session tokens
Goal: prevent hijacking and avoid fixation
Option 1: minimal client-side state
SessionToken = [random unpredictable string]
(no data embedded in token)
Server stores all data associated to SessionToken:
userid, login-status, login-time, etc.
Can result in server overhead:
When multiple web servers at site,
lots of database lookups to retrieve user state.
Option 2: lots of client-side state
• SessionToken:
SID = [ userID, exp. time, data]
where data = (capabilities, user data, ...)
SessionToken = Enc-then-MAC (k, SID)
(as in CS255)
k: key known to all web servers in site.
Server must still maintain some user state:
• e.g. logout status (should be checked on every request)
• Note that nothing binds SID to client’s machine
Binding SessionToken to client’s computer;
mitigating cookie theft
approach: embed machine specific data in SID
Client IP Address:
Will make 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:
A weak defense against theft, but doesn’t hurt.
SSL session key:
Same problem as IP address (and even worse)
MORE ON CROSS SITE
SCRIPTING (XSS)
Recall: reflected XSS
search field on [Link]:
[Link] ? term = apple
Server-side implementation of [Link]:
Echo search term directly into HTML response
(no filtering of user input)
To exploit, attacker crafts a URL containing a script
[Link] ? term =
<script> do_something_bad </script>
Reflected XSS: the exploit
send XSS URL
browser
boom
[Link]
attacker
click on
URL
user
logs in
Bad things happen:
respond
with • [Link] session token
attacker’s [Link] sent to attacker
script
• rewrite [Link] DOM
• rewrite links and persist
Persistent XSS
XSS script is injected into blog, message board, etc.
When user’s view the block, the malicious script
runs in their browser
blogs must filter uploaded content
The famous MySpace Samy worm: (2005)
Bypassed MySpace script filters
Script spread from user to user making everyone
Samy’s friend
[Link]
Persistent XSS using images
Suppose [Link] on web server contains HTML !
request for [Link] results in:
HTTP/1.1 200 OK
…
Content-Type: image/jpeg
<html> fooled ya </html>
IE will render this as HTML (despite Content-Type)
• Consider photo sharing sites that support image uploads
• What if attacker uploads an “image” that is a script?
Universal XSS
• Adobe PDF viewer “feature” : (version <= 7.9)
[Link] # whatever=javascript: --- code –
viewer will execute the javascript in origin of current domain!
• Any site that hosts a single PDF is vulnerable to XSS !
(in fact, PDF files in Windows can also be used)
