WebSec 101
Session Management
Presented By
Mike Andrews
[Link]@[Link]
mike@[Link]
Copyright © 2009, McAfee, Inc. Intro Music by DoKashiteru via CCMixter
Application State
► HTTP(s) is a stateless protocol
● Each request-response is independent
● Served the web very well in it’s early days
● Allowed the web to scale rapidly on minimal resources
► Applications need state otherwise…
● Authenticate on each request
● No concept of “where” in an application flow a user is
● No separation of users in a multi user system
Stateless HTTP
► HTTP needs state as an application platform
► Two methods
● Pass entire state back and forth between client and
server
● Have “identifier” that then is used to lookup state
► Various ways at doing this
● URL munging ([Link]/8772649/[Link])
● State parameters ([Link]/[Link]?id=8772649)
● Cookies
HTTP adds cookies
► Cookies never made it into the HTTP spec until
1994
● [Link]
● [Link]
● Effectively name=value pairs of (semi) persistent
data
► Browsersautomatically send cookies to the
corresponding server on each request
● Have to match properties (path, expires, etc)
● Transparent to the user (and client-side code) – was
specifically a server-side technology
From cookies to state
► Ifserver application code needed to store a
value it could now using a cookie
● Still can be tampered with
● But each user can now be given a “session”, and a
“token” to that session stored within a cookie
► Everymajor web programming platform
supports server-side data storage using sessions
► However, if you could grab a users session
token, you effectively “become” that user
Protect the session token
► At all costs, the application has to protect the
session token
● From before authentication to after logout
► Session token should have good “entropy”
● Session token shouldn’t be easy to guess or derive
► Attack patterns
● Session Fixation ● Weak tokens
● MITM hijacking ● Token reuse
● DOM hijacking
Session Fixation
► Attack Pattern
● Attacker “fixes” or “gives” victim session token
Cookie = 1234
[Link]
Cookie = 1234
Account
Homepage
[Link]
/[Link]
Info
Cookie = 1234
u=joe&p=asdf
Session Fixation
► Mitigation
● Always reissue session token after the following
− Authentication
− Role changes / before sensitive operation
● Don’t allow for session token to be set via GET
parameters
MITM Hijacking
► Sessiontoken is effectively an alias for
username/password for a period of time
● Have to secure it as such
► Browser sends cookie(s) for every matching
request
● Not just for dynamic pages – image requests as well
► Very easy to inadvertently disclose session
token over an insecure channel
● Be aware (fix) “mixed-content” http/https pages
● HTTP is MiTM-able and can be used to attack HTTPS
pages, site, cookies, etc – see XSSI
MITM Hijacking
► Ensure session cookie isn’t sent over an
insecure channel
● Look for SECURE flag on session cookie
► If
site is HTTP only (no HTTPS) consider other
methods
MITM Hijacking
► ASP – [Link]
<[Link]>
...
<httpCookies httpOnlyCookies="true" requireSSL=“true"
domain="" />
...
</[Link]>
► PHP - [Link]
session.cookie_secure = "1"
DOM Hijacking
► Common target for XSS attacks in session cookie
● “Steal” the cookie using [Link]
● More on XSS in another webcast
► Toprotect cookie stealing via this method, ensure
no XSS vulnerabilities in the application
● Very difficult to guarantee this
● Add HTTPOnly to session cookies
► HTTPOnly supported by IE > 6 and FF > [Link]
● [Link] returns empty string for these cookies
DOM Hijacking
► ASP – [Link]
<[Link]>
...
<httpCookies httpOnlyCookies="true" requireSSL=“true"
domain="" />
...
</[Link]>
► PHP - [Link]
session.cookie_httponly = "1"
Weak Tokens
► Notmuch point in protecting the token if it
can be guess or is predictable
● Token should have good “entropy” – randomness
● Have large enough “space” for active user base
Weak Tokens
► Ideally tokens should be > 128 bits
● 340,282,366,920,938,463,463,374,607,431,768,211,455
● 252 addresses for every star in the known universe
● May seem very large, but don’t have to exhaustively test
every value – just have to get one hit
Character Set Bits per Min. length to obtain
char 128-bits
Hex 4 32
Printable ASCII 7 19
Numeric 4 32
Letters 5 26
Letters (case sensitive) 6 22
Token reuse / expiration
► Tokens are “at risk” all the while the session is
valid
► Have
to ensure that sessions are “expired”
when they are not needed
● On logout
● If session is unused for a given interval
Token reuse / expiration
► To Test
● Navigate application -> Capture request
● Logout or allow session to expire
● Replay request
► Ensure that session expires on server as well as
client
► To mitigate
● Most frameworks support this natively (20 min default)
− PHP - session.gc_maxlifetime
− [Link] - <sessionState timeout="40" />
Conclusions
► Session tokens are the most effective way of
giving applications state
● Both performance and security
► Have to protect the session token as it’s
effectively an alias for username/password
● Require HTTPS and HTTPOnly for session cookie
► Make sure session tokens can’t be guessed or
preset
Next Up: Cross-Site Scripting
Credits/References
► Probability of “guessing” a valid session
identifier vs user space
● [Link]
04/[Link]
► Cookie-forcing
● [Link]
_id=126
● [Link]
-[Link]
► Session configurations
● [Link] – see MSDN for [Link] settings
● PHP - [Link]
Credits/References (cont.)
► [Link] doesn’t invalidate session cookie at
logout
● [Link]
apers/[Link]
