- For some people, it's a way to verify the integrity and authenticity of a cookie value. They don't want to be fooled by malicious users.
- For others, it's a way to store confidential data on user browser. And by confidential, they mean CONFIDENTIAL : no user (even if they have the "Malicious certification") have to see the data stored in the cookie. Only the web application has to do it.
- And for some others, a secure cookie can't be intercepted and replayed by malicious users (on untrusted network/computer).
You may ask : "Why do I have to put sensible/confidential data in cookies ? There is server side sessions to store these data ! Cookies are as unsafe as the wireless network of my grandmother ! And god know she don't want to know what WPA and Wardriving is ! Do you like to play with fire ?"
To answer you : yes, i'ts fun to play with fire, i like it !
For the cookie things, yes you can store your data in session on your server. But think twice before using sessions : session state is evil ! Anyway, session evilness it's not the question : if you use sessions, you probably have to store a sessionID in a cookie. This cookie is very important... it must be secure :) Most web applications are concerned by cookie security .
So, depending on nature of the data you want to store in cookies, your must consider all of these points (authenticity, integrity, confidentiality, replay attacks, cookie interception) and select which of them you want to apply.
For each problem, there is a (cryptographic) solution :
- The data integrity and authenticity problems can be solved by cryptographic hashing functions. We will focus on HMAC.
- The confidentiality problem can be solved with use of cryptographic bloc cipher. We will focus on AES.
- The replay problem can be resolved with a mix of HMAC and SSL.
- The interception risk can be reduced with a secure transport protocol, like SSL or TLS. But in fact, it's not a real problem (for cookies I mean) because if a cookie value is encrypted, not replayable and not modifiable... it becomes mostly harmless.
So, if you are still reading, you may be interrested in concrete solutions and crunchy details ? Then I invite you to read this paper : "A Secure Cookie Protocol" by Alex X. Liu.
In the next article, I will give you an implementation of this protocol : some PHP classes and a way to integrate it in Zend Framework.
Comments are welcome :)
2 comments:
There is an obvious flaw in the logic (and protocol) of Liu, Kovacs, Huang, and Gouda.
Specifically (quoted from the paper):
(Section 2.3 - Replay Attacks)
"an attacker first collects a large number of messages that are encrypted by the same SSL session key, and then obtains the SSL session key using various methods. In the second step of a replay attack, the attacker initiates an SSL connection with the server and replays a stolen cookie that has not yet expired."
Followed by their purported 'fix' stating:
"To counter replay attacks, we propose to add the SSL session key into the keyed-hash message authentication code of a cookie, i.e., to use HMAC(username|expiration name|data|session key, sk) as the keyed-hash message authentication code of each cookie. Therefore, a cookie becomes session specific. Even if an attacker steals a cookie, he cannot successfully replay it since the session key is known only to a legitimate client and the server that creates the cookie."
If it's not obvious, they are stating that the reason Fu's cookie protocol is vulnerable to replay attacks is due to the fact that the SSL Session Key can be found by a clever attacker with enough data.
Their 'solution' to this problem is to use that same vulnerable SSL Session Key to 'protect' the cookie against replay attacks.
This makes no sense.
Look, breaking SSL, or even obtaining an SSL Session key is no small or easy task (in most cases), however they are basing their claim that their protocol is superior on the fact that Fu's is somehow more vulnerable to replay attacks (generally the primary concern of cookies in the first place). Seems to me that this protocol garners no more or less protection against these attacks then their obvious rival protocol.
I know that the post and the comment I am replying to are very old, but I hope my contribution will help other people who are interested in this protocol.
I would like to point out that there is an obvious flaw in the logic of your rebuttal and you are quoting them out of context.
Finding the SSL session key is only one way of stealing the cookie, and they do mention the others.
Stating that:
They "use that same vulnerable SSL Session Key to 'protect' the cookie against replay attacks", you show a lack of understanding of Liu's protocol.
It is not enough know the initial SSL session key to do a replay attack, you also need to trick the server into using the same session key when you do the replay, which is exactly what the SSL session negotiation is designed to prevent.
Post a Comment