WebSec 101

Session Management

Presented By
Mike Andrews
mike.andrews@foundstone.com
mike@mikeandrews.com

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 (www.example.com/8772649/page.cgi)
● State parameters (www.example.com/page.cgi?id=8772649)
● Cookies
 HTTP adds cookies

► Cookies never made it into the HTTP spec until

1994
● http://www.w3.org/Protocols/HTTP/HTTP2.html
● http://www.w3.org/Protocols/rfc2109/rfc2109
● 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

bank.example.com
Cookie = 1234

Account
Homepage
bank.example.com
/login.asp
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 – Web.config

<system.web>
...
<httpCookies httpOnlyCookies="true" requireSSL=“true"
domain="" />
...
</system.web>

► PHP - php.ini

session.cookie_secure = "1"
 DOM Hijacking

► Common target for XSS attacks in session cookie

● “Steal” the cookie using document.cookie
● 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 > 2.0.0.5

● document.cookie returns empty string for these cookies
 DOM Hijacking

► ASP – Web.config

<system.web>
...
<httpCookies httpOnlyCookies="true" requireSSL=“true"
domain="" />
...
</system.web>

► PHP - php.ini

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
− ASP.NET - <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
● http://www.blackhat.com/presentations/bh-usa-
04/bh-us-04-shema-up.pdf
► Cookie-forcing
● http://conference.hitb.org/hitbsecconf2009dubai/?page
_id=126
● http://scarybeastsecurity.blogspot.com/2008/11/cookie
-forcing.html
► Session configurations
● ASP.NET – see MSDN for web.config settings
● PHP - http://www.php.net/manual/en/ref.session.php
 Credits/References (cont.)

► ASP.NET doesn’t invalidate session cookie at

logout
● http://www.foundstone.com/us/resources/whitep
apers/aspnetformsauthentication.pdf