2

I'm creating a web application, and want to allow users to log in (and stay logged in). My plan to support this in a secure way goes as follows:

  • User logs in from a login form - when successful, the server responds with a secure and HttpOnly cookie that simply contains their username.
  • When the user closes their browser and later comes back, a request is submitted (which includes the cookie) to an endpoint on the server upon page load that asks the server if the current user is logged in, which the server determines by the presence of the cookie. If so, the server returns the value of the cookie, which the client-side can display on the UI as the user's username.

  • Any request that requires an authenticated user (such as saving or updating data) will do so under the name of the username specified in the cookie in each given request.

One major question I have - if someone goes into their browser and manually changes the username cookie using devtools, would this allow them to make requests under the guise of another user with the way I have this laid out? Or does HttpOnly prevent this?

Am I overcomplicating this? Do I gain anything by making this cookie HttpOnly, since I'm essentially allowing the clientside to read it anyways? Is my approach even secure?

2 Answers 2

2
  • the secure Flag ensures that the cookie is only send via https, not in plaintext, see OWASP SeucreFlag
  • with the httpOnly attribute set, a cookie can not be modified by client side javascript, see OWASP HttpOnly

Now to your Question:

if someone goes into their browser and manually changes the username cookie using devtools, would this allow them to make requests under the guise of another user with the way I have this laid out? Or does HttpOnly prevent this?

No httpOnly does not prevent the described scenario in your question. Someone who has access to the browser can modify the cookie, because in this case no script is needed to modify the cookie.

Any request that requires an authenticated user (such as saving or updating data) will do so under the name of the username specified in the cookie in each given request.

It would be better to set a random sessionId (session token), something which is harder to guess than a username. This would prevent the described impersonation attack (guessing a username). For more information about session managment see OWASP Session Management

2

No, your approach is definitely not secure.

HttpOnly is intended to prevent malicious Javascript from accessing the cookie. A malicious user with access to the browser (including the user himself) can do whatever they want to the cookies, or even ignore them and make up their own cookies to submit with the request.

If you would like to keep something somewhat close to your existing design, I would suggest encrypting or signing the contents of the cookie in order to make it tamper-resistant. Another option is to simply store a session identifier in the cookie (with sufficient entropy) and store the user ID in session state on the server side.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .