1

I'm currently in the middle of a vulnerability assessment and have found the cookies do not have Secure or HttpOnly set. I have recommended they set both of these to true for their cookies, but the developers have replied with they are not going to, for the following reasons:

  • They won’t be able to delete the cookie when logging out via javascript
  • The cookie is only used for meta data, not to authenticate data requests

Is this a valid defense? I can't find any (security related) reasons for choosing to delete a cookie over setting Secure and HttpOnly.

|improve this question
  • Their answer doesn't seem to make sense. If they need to delete cookies when logging out, then that sounds like authenticated data. At best is sounds like they need to give you a better explanation. Ultimately, there is no single right or wrong answer...You (and they) need to understand the threat model and why these choices are, or are not a risk. – Xander Dec 31 '18 at 19:22
1

Secure flag has nothing to do with javascript involvement . It only enables or disable the transmission of cookies over insecure plain-text in case the server entertain http and https requests. In fact, not setting it makes their app vulnerable to cookie hijack on the fly

HttpOnly flag , yes it definitely imposes some restriction on javascript reading the cookie , but defence against clickjack and XSS , hope they have this knowledge because there is no compulsion of logout to make cookies accessible to javascript

|improve this answer
1

Login/session tokens or tokens that carry user data have to be Secure and HTTPOnly, or they become a security issue.

Explicitly hitting a logout button, rather than just token expiry, results in a "logout" request to the server. Have the server invalidate the authentication token (cookie) but setting it to some junk value. For example, Set-Cookie: token=loggedout.

Deleting a cookie may be a client side action, but setting a cookie can be done on the server side and you can still maintain HTTPOnly and Secure (which, as 8zero2.ops pointed out, is unrelated to this issue).

|improve this answer
  • I wish I could accept everyone's reply as an answer. Thanks for the helpful responses. – user127507 Oct 21 '16 at 15:37
  • Even if you didn't want to round-trip a new page to reset the cookie, the JS can tell the server that the session has expired (so it won't honour it in future) and could create a non-HTTPOnly cookie to tell the app the next time it runs that the (inaccessible, HTTPOnly session cookie) is invalid. – TripeHound Aug 17 '18 at 12:36
0

You can ask them to expire the cookie when the user visits the website. And if the cookie contains sensitive information (session id) you must invalidate the session at the server side.

|improve this answer
0

It sounds like these are session id cookies, in which case they most certainly should want to have httponly and secure flags set. Cookies need to be managed by the server and not the client. The implication of the developers in this case is that they are placing too much trust in the data received from the client, which is very bad. I would refer them to the OWASP Session Management Cheat Sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy