Secure Session Management
•
2 likes•2,777 views
This document discusses secure session management and common session security issues. It explains that capturing a user's session allows an attacker to act as that user. Sessions need to be properly terminated on logout to prevent replay attacks. Weaknesses like cookies set before authentication, non-random session IDs, and failing to remove sessions on logout can enable session hijacking. The document provides guidelines for generating secure random session IDs, setting cookies only after authentication, removing sessions on logout, and using HTTPS to mitigate these risks.
Report
Share
Secure Session Management
- 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. 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. 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. 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
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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