Web App Session Management security risks and countermeasures
Session management is a fundamental feature of a majority of web applications. Since http is stateless then sessions are typically what allows application to uniquely identify users across requests. If an application allows a user to login then the session is even more important because it also identifies a user as being authenticated.
Even if a user does not login, sessions are used for features such as carts for guest users.
All this makes sessions a prime target for hacker attacks. If a hacker can access a session then they can impersonate a user i.e. they can "hijack" a session and pretend to be that user.
The most common session technique is to issue each user with a session id/token. On each request the session id is submitted and the app on the server can then identify the user. HTTP Cookies are used in most cases to exchange session id. The server responds with a "Set Cookie" HTTP Header and thereafter the browser sends the cookie back to the server in the Request header (if appropriate per cookie domain and path and secure setting).
Session vulnerabilities fall into two categories:
1. Weakness in generation of session token. Easy to predict, crack and otherwise discover tokens are the risks here.
2. Weakness in handling session token
- Using https for login but reverting to http thereafter (common among eCommerce sites) so the session id is visible to eavesdropping. Firesheep (or wireshark) is a good example of a simple app to eavesdrop and capture sessions.
- Web app accepting http requests for https pages
- Not expiring the session properly. Should have automatic expiration time on the session on the server.
- Not invalidating the session on the server. Users should have a logout option which should invalidate the session on the server. Its not enough to invalidate the session cookie.
- Not setting session cookie scope property. This includes cookie domain and path.
- Disclosing session in logs
Countermeasures
The best countermeasure is to use https for all instances where exchanging session cookie (and make the cookie secure).
Shortly after the "Firesheep" Firefox pluginwas released Facebbok and Gmail converted to all https. The performance impact of https is less nowdays but still slower than http.But all htpps is not an option for many eCommerce sites which are a mix of http and https e.g. Account and Checkout are https but many other pages such as home, help, pdp, subcat and cart are not.
If a hacker can eavesdrop on an unencrypted newtwork (such as in an internect cafe with unencrypted wireless) then they can see session cookies being exchanged over http. These can then be hijacked.
But many sites live with this risk and accept the tradeoff (at this time).
Countermeasures are related to the 2 main threats:
1. Generate Strong Tokens
- Should not be possible to predict or extrapolate tokens. Tokens should be nothing more than id with no meaning or structure.
- Steps should be taken to introduce additional randomness (entropy) such as time of request, user agent or even a secret server string, add that to the base token and then hash it (e.g. md5). Putting variable items at the front makes the token more random.
2. Protect session tokens throughout their lifecycle
- Only transmit cookies over https and make cookies secure so browser only sends the cookie over https. If that's not possible then any requests to sensitive pages should redirect to https. Scope cookies appropriately e.g. no need for session cookie to be sent for help pages.
- Never transmit session in the url
- Provide users logout link which invalidates session in the server
- Implement session expiration which does same as logout
- Prevent concurrent logins
- Session cookie domains and path should be as restricted as possible
- Create a fresh session token after login and logout
- protect against cross site scripting and forgery attacks
Many eCommerce sites avoid storing credit card information or other high risk personal data in their system, thus avoiding having to deal with PCI compliance and if a users session is hijacked then at least credit card details are not compromised.
In addition personal data should bot be displayed back to the user at all, credit card info and passwords should be masked.
Great reference: "The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws"
Countermeasure for Session Hijacking
One additional countermeasure to those listed above is a countermeasure against session hijacking by unencrypted network traffic sniffing which we implemented as follows:
1. when a user logs in is to create a secure cookie (only exchanged over https and thus won't be seen), path scoped to profile pages (thus not unnecessarily sent), httpOnly set, which has a generated value which is also set in the session and expires after x seconds.
2. Each time the user visits a profile page (accessible only if logged in) then the code checks that the secure cookie has a value which matches the value in the session.
If not, then we force logout and redirect to signin page
3. when users logout don't forget to delete that cookie
Notes on php cookies and more
- if you set path to '' then the cookie path is automatically set to current folder.
- you can set time to 1 and that will expire the cookie
- I have found that when expiring/deleting cookie the path must match the path used to set the cookie
- prefer all lowercase cookie names
- always use httpOnly for cookies unless you need to access using client javascript. Good Article: http://www.academia.edu/1324930/Why_Arent_HTTP-only_Cookies_More_Widely_Deployed
"HTTP-only cookies only prevent cookies from being accessed through the DOM in scripting-related attacks, but provide no defense against other ways of stealing cookies.Another way to steal cookies is to eavesdrop on network traffic.
Even if a user does not login, sessions are used for features such as carts for guest users.
All this makes sessions a prime target for hacker attacks. If a hacker can access a session then they can impersonate a user i.e. they can "hijack" a session and pretend to be that user.
The most common session technique is to issue each user with a session id/token. On each request the session id is submitted and the app on the server can then identify the user. HTTP Cookies are used in most cases to exchange session id. The server responds with a "Set Cookie" HTTP Header and thereafter the browser sends the cookie back to the server in the Request header (if appropriate per cookie domain and path and secure setting).
Session vulnerabilities fall into two categories:
1. Weakness in generation of session token. Easy to predict, crack and otherwise discover tokens are the risks here.
2. Weakness in handling session token
- Using https for login but reverting to http thereafter (common among eCommerce sites) so the session id is visible to eavesdropping. Firesheep (or wireshark) is a good example of a simple app to eavesdrop and capture sessions.
- Web app accepting http requests for https pages
- Not expiring the session properly. Should have automatic expiration time on the session on the server.
- Not invalidating the session on the server. Users should have a logout option which should invalidate the session on the server. Its not enough to invalidate the session cookie.
- Not setting session cookie scope property. This includes cookie domain and path.
- Disclosing session in logs
Countermeasures
The best countermeasure is to use https for all instances where exchanging session cookie (and make the cookie secure).
Shortly after the "Firesheep" Firefox pluginwas released Facebbok and Gmail converted to all https. The performance impact of https is less nowdays but still slower than http.But all htpps is not an option for many eCommerce sites which are a mix of http and https e.g. Account and Checkout are https but many other pages such as home, help, pdp, subcat and cart are not.
If a hacker can eavesdrop on an unencrypted newtwork (such as in an internect cafe with unencrypted wireless) then they can see session cookies being exchanged over http. These can then be hijacked.
But many sites live with this risk and accept the tradeoff (at this time).
Countermeasures are related to the 2 main threats:
1. Generate Strong Tokens
- Should not be possible to predict or extrapolate tokens. Tokens should be nothing more than id with no meaning or structure.
- Steps should be taken to introduce additional randomness (entropy) such as time of request, user agent or even a secret server string, add that to the base token and then hash it (e.g. md5). Putting variable items at the front makes the token more random.
2. Protect session tokens throughout their lifecycle
- Only transmit cookies over https and make cookies secure so browser only sends the cookie over https. If that's not possible then any requests to sensitive pages should redirect to https. Scope cookies appropriately e.g. no need for session cookie to be sent for help pages.
- Never transmit session in the url
- Provide users logout link which invalidates session in the server
- Implement session expiration which does same as logout
- Prevent concurrent logins
- Session cookie domains and path should be as restricted as possible
- Create a fresh session token after login and logout
- protect against cross site scripting and forgery attacks
Many eCommerce sites avoid storing credit card information or other high risk personal data in their system, thus avoiding having to deal with PCI compliance and if a users session is hijacked then at least credit card details are not compromised.
In addition personal data should bot be displayed back to the user at all, credit card info and passwords should be masked.
Great reference: "The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws"
Countermeasure for Session Hijacking
One additional countermeasure to those listed above is a countermeasure against session hijacking by unencrypted network traffic sniffing which we implemented as follows:
1. when a user logs in is to create a secure cookie (only exchanged over https and thus won't be seen), path scoped to profile pages (thus not unnecessarily sent), httpOnly set, which has a generated value which is also set in the session and expires after x seconds.
2. Each time the user visits a profile page (accessible only if logged in) then the code checks that the secure cookie has a value which matches the value in the session.
If not, then we force logout and redirect to signin page
3. when users logout don't forget to delete that cookie
Notes on php cookies and more
- if you set path to '' then the cookie path is automatically set to current folder.
- you can set time to 1 and that will expire the cookie
- I have found that when expiring/deleting cookie the path must match the path used to set the cookie
- prefer all lowercase cookie names
- always use httpOnly for cookies unless you need to access using client javascript. Good Article: http://www.academia.edu/1324930/Why_Arent_HTTP-only_Cookies_More_Widely_Deployed
"HTTP-only cookies only prevent cookies from being accessed through the DOM in scripting-related attacks, but provide no defense against other ways of stealing cookies.Another way to steal cookies is to eavesdrop on network traffic.
Comments
Post a Comment