In the first blog post we talked about the dangers that your cookies are exposed. Now it is time to keep your cookies safe. Time to know what protection mechanisms there are, how to use them and why.
How to read this post?
The flowchart below will guide you to the process to check if your cookies are well protected. Note that there are more factors and cases that could potentially compromise your cookies (as we talked in the part 1 of the blog post).
Of course at the end of the post you will find the explanation to the flowchart. So if you do not understand anything, do not panic! Look for the question in the last part of the blog where it will be explained.
A flowchart about how to get your cookies better secured.
Is your session cookie different before and after login?
- Correct answer: Yes, if your unique session ID cookie is different after and before login, your session is correctly protected against Session Fixation attacks
- Incorrect answer: No, your unique session ID cookie is the same, if an attacker managed to stole your cookie before login into the web application, then once you are authenticated the attacker could also access the application
Recommendation: Session ID should be changed after and before user logs in.
Are you invalidating the session when the user logs out?
- Correct answer: Yes, once the user has logged out, the session must be destroyed or invalidated
- Incorrect answer: No, if you do not destroy the session ID in server side, the session will continue being valid
Recommendation: Session must be invalidated after the user logs out.
Does your cookie have the attribute “HttpOnly”?
- Correct answer: Yes, your cookie is only accessible via http and not via JavaScript
- Incorrect answer: No, your cookie is also accessible via JavaScript , which in case of an attacker compromise your application with a Cross-site Scripting, it could access to your cookie
Recommendation: Set the cookie as “HttpOnly”.
Does your cookie have the full domain attribute set?
- Correct answer: Yes, your cookie is only being sent to the correct domain where it is needed
- Incorrect answer: No, your cookie can be sent to the multiple sub-domains you could have
Recommendation: The full domain of the cookie must be specified.
Does your cookie have an adequate lifetime?
- Correct answer: Yes
- Incorrect answer: No, Cookies with an excessive lifetime will not be deleted when the user closes their browser and would therefore be exposed should an attacker manage to compromise the user’s system
Recommendation: Use cookies without a lifetime so that they are deleted once the user closes their browser or lower its lifetime to meet business requirements.
Do you have only one web application in the same domain?
What does this question mean? The following is an example of multiple web applications in the same domain:
- www.mydomain.com/app1
- www.mydomain.com/app2
- www.mydomain.com/app3
There is not a correct answer to this question.
If you only have one application running over the same domain, you should not need to care about this issue. However if you host multiple web applications, you need to set the attribute “path” of the cookie to ensure that the cookie is only being sent to the web application it belongs.
Are your cookies NOT storing sensitive information?
- Correct answer: Yes, my cookies do not contains sensitive information
- Incorrect answer: No, there are some sensitive information in the cookies
Recommendation: Ensure that sensitive information is not stored in the cookies.
Does your web application support HTTPS?
If the answer to this question is NO, you are sending all the data through a plain text protocol. An attacker able to intercept network traffic between a user’s session and the web server could capture the sensitive data being transmitted.
If the answer is YES, there is some other question you need to answer before know if you are protecting correctly your cookies:
Does your web application use HTTP + HTTPS (mixed content)?
If the answer is NO, it means that HTTP is not allowed and all the data is being sent over HTTPS. Although your cookie is secure in this case, you need to be careful if you enable HTTP.
If the answer is YES you need to answer one more question:
Is HSTS (HTTP Strict Transport Security) enabled or has the cookie the attribute “secure”?
If you have HSTS enabled, you are forcing all the data being sent over HTTPS (cookies included).
If the cookie has the attribute “secure”, you are forcing the cookie to be sent only over HTTPS.
Recommendation: Set the cookie as “secure” and consider to enable HSTS.