session1
TRANSCRIPT
Copyright © 2009, McAfee, Inc.
Presented By
Mike Andrews
Session Management
WebSec 101
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