I'm designing a cookie for authentication purposes. In case of success, this will go into an application.

Here are the things I've included in this cookie:

  • It's for web of course
  • It includes some data about the authenticated user, for performance purposes (UserId is the least data)
  • It includes a salt (extra data) that is only known to the server, to prevent cookie-forgery attacks
  • The whole cookie's value is encrypted via AES
  • It appends a token from client data for the purpose of preventing cookie-hijacking (client IP is not included because of each network change, another login would become mandatory). In fact, it only includes UserAgent header
  • It's HttpOnly, to prevent from XSS attacks gaining access to cookie (yet still vulnerable to CSRF)
  • It's expiration is set to one month, because of better UX (people don't like to always login after closing the browser)

We've done this till here, and tested and it works just fine. What possible attacks are still possible via this design and how can we make it more secure?

  • What are you doing to prevent CSRF attack? Apr 1, 2017 at 7:53
  • What should I do? I have no idea. Checking origin? creating one-time tokens? Apr 1, 2017 at 9:54
  • Go here: owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) and choose a method depending on your architecture. Do you use REST service and need to be stateless or you hava a state? Depending on that choose the method. Come back here if you have soecific questions. Apr 1, 2017 at 12:34
  • @MarkoVodopija, thanks for the link. That's for CSRF and I will implement a counter-measure. What about cookie hijacking? Right now if you use Chrome-52 and I steal your cookie over the wire and manually set it in my Chrome-52, then I would be able to continue sending requests. Does that have a solution at all? Because not even via a browser, all I can do is to sniff a simple request/response, and spoof a request via any coding platform. Apr 1, 2017 at 13:12
  • You can generate unique number for each token and store it in the database. That way you can revoke a token if it gets stolen. Take a look at JWT, it is a token standard that will help you encapsulate all this in a standard way. It doesn't matter whether you are deploying it with cookies or some other way, what you generating is a token. Apr 1, 2017 at 18:26

2 Answers 2

  • Use the SameSite flag to prevent CSRF attacks.
  • Use cookie prefixes to prevent cookie clobbering.
  • Use a HMAC to prevent cookie tampering. You say you have prevented this using a salt. It is unclear what this means, and if it is not a HMAC it is probably not the correct way to prevent tampering by the client.

At the end of the day, CSRF is the security issue you have to handle when using cookies. Make sure all URLs that manipulate state require some sort of confirmation that the user is intentionally sending the request.

Many web frameworks have this built in for state-changing request methods. Django does this by including a "CSRF token" attached to the relevant form.

The important thing is to not have GET requests that alter state. This is asking for trouble and how CSRF is easily implemented.

You must log in to answer this question.

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