Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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	
ab...
What	is	a	session	and	why	is	it	
necessary?
• A	session	is	a	series	of	interactions	between	two	
end	points	that	occurs	du...
What	needs	to	happen	to	establish	a	
session?
• Authentication
• NTLM	– hash	of	windows	credentials	used	to	identify	
user...
What	are	some	types	of	HTTP	session	
tracking?
• HTTP	– Hypertext	Transfer	Protocol
• Foundation	 for	communication	on	wor...
What	are	some	types	of	session	
tracking?	(cont.)
• Cookie-based
• A	user	visits	a	website	and	the	server	responds	with	a	...
Cookies
• Cookies	are	small	pieces	of	data	set	on	a	client	
machine	so	the	web	server	can	uniquely	
identify	the	requestin...
Common	security	concerns
• Some	session	tracking	weaknesses	we	
commonly	see
• Cookies	not	reset	after	authentication
• Se...
Cookies	set	prior	to	authentication
• When	a	user	visits	a	website,	they	are	
presented	with	a	session	cookie
• The	user	h...
Cookies	set	prior	to	authentication	
(cont.)
• These	attacks	can	allow	the	attacker	to	duplicate	
the	user’s	session	and	p...
Session	not	properly	terminated	on	
logout
• When	a	user	logs	out	of	an	application,	the	
session	is	not	properly	terminat...
Session	not	properly	terminated	on	
logout	(cont.)
• These	attacks	are	another	avenue	that	can	
allow	the	attacker	to	dupl...
Cookies	not	random	enough
• When	a	user	visits	an	application,	the	cookies	can	
contain	any	of	the	following
• A	timestamp...
Cookies	not	random	enough	(cont.)
• When	a	session	can	be	predicted,	an	attacker	
can	gain	access	to	multiple	sessions	tha...
Guidelines	for	secure	cookie	management
• Session	tracking	cookies
• Set	and/or	reset	value	after	authentication	
• Remove...
Common	session	management	attacks
• We	will	now	discuss	some	ways	in	which	weak	
session	management	is	commonly	exploited
...
Cross-site	scripting	to	exploit	weak	session	
management
• Cross-site	scripting
• One	of	the	goals	of	this	style	of	attack...
Cross-site	scripting	to	exploit	weak	session	
management	(cont.)
– Leverage	document	
object	model	to	access	
cookie
– Sol...
Other	attacks	leveraging	session	
weaknesses
§ Cross-site request forgery
o An attacker can leverage a user’s existing ses...
Other	attacks	leveraging	session	
weaknesses	(cont.)
• Session	cloning
• Leverages	session	tracking	weaknesses
– Session	t...
Some	steps	to	help	avoid	attacks
• Filter	client	supplied	input	for	proper	size	and	characters	
before	being	processed	by	...
Questions?
December 15,2015
Upcoming SlideShare
Loading in …5
×

Secure Session Management

631 views

Published on

Presentation given by Brian Beaudry at OWASP Tampa Chapter meeting on Thursday, December 10, 2015.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Secure Session Management

  1. 1. Secure Session Management OWASP Tampa December 10, 2015 December 15,2015
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. Questions? December 15,2015

×