Other ways to protect cookies

I've been thinking about this a lot lately, and I wanted to know if anyone thought of any intuitive ways to protect cookies from manipulation. I've always used "sign it with a hash and check against a hash later", but it doesn't show me how particularly brilliant a way to get around it, and like all good programmers, I want to find a better way to do it.

As for why cookies specifically, well, I don't use my own sessions - I don't like touching the filesystem. Cookies are a really fast way to store data for later versions and even with things like user authentication. I'll loop the user id in a cookie, possibly along with the username / email and signature, and a random hash for a good measure.

What clever ways have you used to protect your cookie data?

+2


source to share


4 answers


Signing a cookie with HMAC is a perfectly sane way to do this. HMAC essentially translates a private key known only by your server into a hash, so even someone who knows the algorithm cannot generate an HMAC that is valid without knowing the key. Simply using a plain old hash is trivial to work around because an attacker could generate valid hashes of their own data, and all the salt in the ocean won't fix it.

Even if you used the session ID instead of storing meaningful values, you still need to be careful that an attacker cannot predict another correct session ID and send it instead, thereby hijacking another user session. I believe there was an actual exploit against Hotmail that worked this way.



Cookie encryption only helps if you don't want to see it there. Worse, encryption without HMAC gives a false sense of security because a cookie that is simply encrypted is still vulnerable to manipulating the ciphertext to alter parts of the plaintext.

So, don't just have a hash, use HMAC!

+1


source


How do you store the UserID in a cookie and grant the user access based on that value? You are asking for trouble. Server session based data implementations exist for good security reason: store the session ID in a cookie and access the user ID from a record on the server where the client cannot tamper with it.



Protecting cookies to protect against unauthorized customer intervention is largely a lost cause. Given enough time, someone will figure out how to hack it. Don't give clients this opportunity. Cookie-only security is to ensure that cookie clients are not stolen.

+2


source


With hashing, you need to be very careful that you include the salt, otherwise it might be trivial to figure out the appropriate hash.

Thus, to protect against accidents, it is often advisable to encrypt the cookie as well.

- edit

You can also learn about HTTPOnly cookies: http://www.owasp.org/index.php/HTTPOnly

+1


source


In the Security Now podcast (I forgot which episode) Steve Gibson talks about doing something like this, and I think the system he recommended was to make the content of the cookie a good hash and then do this hash key is in your local database, where value (s) are (all) information that it should store.

0


source







All Articles