Copyright © 2009, McAfee, Inc.

Presented By

Mike Andrews

Session Management

WebSec 101

mike.andrews@foundstone.com

mike@mikeandrews.com

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

► Browsers automatically 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

► If server 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

► Every major 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

● MITM hijacking

● DOM hijacking

● Weak tokens

● Token reuse

Session Fixation

► Attack Pattern

● Attacker “fixes” or “gives” victim session token

bank.example.comCookie = 1234

Cookie = 1234

bank.example.com

Cookie = 1234

/login.asp

u=joe&p=asdf

HomepageAccount Info

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

► Session token 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 –

► PHP -

Web.config

<system.web>

...

<httpCookies httpOnlyCookies="true" requireSSL=“true"

domain="" />

...

</system.web>

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

► To protect 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 –

► PHP -

Web.config

<system.web>

...

<httpCookies httpOnlyCookies="true" requireSSL=“true"

domain="" />

...

</system.web>

php.ini

session.cookie_httponly = "1"

Weak Tokens

► Not much 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

char

Min. length to obtain

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