Secure Session Management
OWASP Tampa
December 10, 2015
December 15,2015

Why are we talking about sessions?
• In general, when we discuss session
management with web applications, if you are
able to capture a user’s session, you can
become that user
• If you can become another user, any controls
you put in place no longer matter
• In a captured session, you are executing
commands as another user
• Session management is, therefore, very
important
December 15,2015

What is a session and why is it
necessary?
• A session is a series of interactions between two
end points that occurs during the span of a
connection
• One end point requests a connection with another
end point and, if that endpoint agrees, the
endpoints exchange data and commands
• The session begins when a connection is
established and ends when the connection is
ended
• Since HTTP is a stateless protocol, there needs to
be a way of tracking sessions through unique
identifiers
December 15,2015

What needs to happen to establish a
session?
• Authentication
• NTLM – hash of windows credentials used to identify
user
• Forms-based - Generic term, commonly HTTP + HTML /
XHTML
• Less Common
– Basic – Base64 encoded, not secure
– Digest – encrypted transmission of credentials, based on
MD5 hash
§ Some session tracking mechanisms
o URL rewriting
o Cookies
• In form-based authentication, cookies are used
to track a user - *JSessionID*
December 15,2015

What are some types of HTTP session
tracking?
• HTTP – Hypertext Transfer Protocol
• Foundation for communication on world wide web
• Stateless
• URL rewriting
• A user visits a website and the server responds with a session tracking
token
• The user then sends requests to the web server which contain the
session ID in the URL
– www.somesite.com/index.jsp?jsessionid=abcdefg1234567
• Cookie-based
• A cookie is a small piece of data set on the client machine so the web
server can uniquely identity the requesting party and maintain a
session
– Cookies can have the following attributes:
» Marked Secure
» Marked HTTPOnly
» Have a path set – which site(s) can use the cookie
» Be set to expire
December 15,2015

What are some types of session
tracking? (cont.)
• Cookie-based
• A user visits a website and the server responds with a
session tracking token
December 15,2015

Cookies
• Cookies are small pieces of data set on a client
machine so the web server can uniquely
identify the requesting party and maintain a
session
• Some common mistakes
• Set prior to authentication
– Not changed post authentication
• Not marked Secure/HTTPOnly
• Transmitted over HTTP
• Transmitted as part of the URL
• Based on static value
• Can be reused
December 15,2015

Common security concerns
• Some session tracking weaknesses we
commonly see
• Cookies not reset after authentication
• Session not properly terminated on logout
• Cookies not random enough and/or persistent
• Cross-site scripting (XSS)
• Cross-site request forgery (XSRF)
• Session replay
• Weak input validation
December 15,2015

Cookies set prior to authentication
• When a user visits a website, they are
presented with a session cookie
• The user has not yet authenticated
• The user authenticates before the cookie
expires and the user’s session is bound to
the session token set by the server prior to
authentication
• Attack
• Capture of credentials at
console
• Persistent cookies on local
machine
• Phishing a user with a URL
that contains a session cookie
December 15,2015

Cookies set prior to authentication
(cont.)
• These attacks can allow the attacker to duplicate
the user’s session and perform actions as that
user
• Perform unauthorized functions
• Gain access to unauthorized information
• Solutions
• If you need a cookie to track a user prior to authentication,
ensure it is not the session cookie
• If you do not need a cookie to track status, do not set one
• Set the session cookie to a new value once the user
authenticates and invalidate the previous cookie so it is not
tied to the user session
• Delete any previous cookies for that user in the session table
December 15,2015

Session not properly terminated on
logout
• When a user logs out of an application, the
session is not properly terminated
• Cookie not removed/overwritten on browser
• More importantly, cookie not deleted from the session table
on the backend server
• Attack scenario
• A user has logged out of the session but leaves the browser
open, walking away from the computer
• A malicious user can use the back button to access data and
perform transactions
• If transmitted in clear-text, once a user logs out, an attacker
who was sniffing traffic can re-submit session traffic and gain
a cloned session
December 15,2015

Session not properly terminated on
logout (cont.)
• These attacks are another avenue that can
allow the attacker to duplicate the user’s
session and perform actions as that user
• Perform unauthorized functions or gain access to
unauthorized information
• Solutions
• Ensure that the logout triggers the following action
– Remove the session token(s) from the session table on the
backend server
December 15,2015

Cookies not random enough
• When a user visits an application, the cookies can
contain any of the following
• A timestamp
• A username
• A cookie that is short in length
• A cookie that is persistent
• A cookie that expires a year or more in the future
• Attack scenario
• A persistent cookie is present on user machines
• An attacker can capture these credentials and replay them
from a remote location waiting for the target user to log in
• If the cookie contains a username and that username
defines permissions, this can be changed and the attacker
can gain elevated privileges
December 15,2015

Cookies not random enough (cont.)
• When a session can be predicted, an attacker
can gain access to multiple sessions that can
• Allow targeted user attacks
• Gain access to sessions at several different user levels
• Solution
• Ensure that random cookies are used
• Ensure that no persistent cookies are used
• Ensure that cookies are not set to expire a long time in
the future
December 15,2015

Guidelines for secure cookie management
• Session tracking cookies
• Set and/or reset value after authentication
• Remove from the session table on the server when the user
logs out
– Reset on browser as well (not vital)
• Use random values --over 128 bit
• Mark the cookie “Secure” and “HTTP-only”
• Ensure the cookie cannot be reused
• Avoid persistent cookies
• Set cookie to expire in a timely manner
• Transmit in the HTTP header instead of the URL line
• Use HTTPS instead of HTTP for transmission
December 15,2015

Common session management attacks
• We will now discuss some ways in which weak
session management is commonly exploited
• What we will discuss are attacks which we find
to be valid with many applications
• Cross-site scripting
• Cross-site request forgery
• Session cloning
• Session fixation
• Session replay
December 15,2015

Cross-site scripting to exploit weak session
management
• Cross-site scripting
• One of the goals of this style of attack is to gain control of a
user’s session
• By crafting a special request which contains a script, the
attacker can attempt to gain a target user’s session tokens
– Simple example
– www.somesite.com/home.html?search=<javascript:alert(test123)
>
• This will cause an alert box to appear with the text “test123”
on the user’s desktop
• Next we will look at a more complicated attack which can be
used to compromise a user’s session
December 15,2015

Cross-site scripting to exploit weak session
management (cont.)
– Leverage document
object model to access
cookie
– Solution
• Filter client supplied
input
– Length
– Special characters
– Etc
• Mark cookies as HTTP-
only
– Ensures cookies
cannot be
accessed by DOM
December 15,2015

Other attacks leveraging session
weaknesses
§ Cross-site request forgery
o An attacker can leverage a user’s existing session to execute
requests from outside that session
o Example
• <img
src=www.somesite.com/attack.htm?target=1234567890&status=att
ack&damage=100>
o Solution
• Do not pass transactional information in the URL
• Functions which require variables to be passed should only be
accepted in POST requests
– GET/POST translation
• Application should validate the referrer when a request is made
• Requests which perform sensitive actions should have a token
associated with them
– Token embedded in page
– Must match backend or request is not processed
December 15,2015

Other attacks leveraging session
weaknesses (cont.)
• Session cloning
• Leverages session tracking weaknesses
– Session token set prior to authentication
– Session token(s) passed in URL
» www.somesite.com/login.htm?jsessionid=1234567890abcd
ef
• Session fixation
• A session token is set via a GET request
– www.somesite.com/login.htm?jsessionid=1234567890abcdef
• Token does not change after login
• Session replay
• A previous session was not properly terminated on the backend
• Perform transactions by replaying captured/sniffed traffic
December 15,2015

Some steps to help avoid attacks
• Filter client supplied input for proper size and characters
before being processed by the backend server.
– Use white list instead of black list for input validation
» Black lists can be bypassed through encoding/new attack
types, etc.
• Do not allow special characters to be processed unless
specifically required by the application
– Encode to prevent execution at the browser
• Mark cookies as HTTP-only so they cannot be
compromised through XSS attacks
• Use addition form-based token for sensitive POST actions
to prevent CSRF attack
– Also check referrer field
December 15,2015

Questions?
December 15,2015