 theSCIENTIST wrote:
...one cause for concern I have is this cookie impersonation bussiness.
I know there's tools out there that can write custom cookies in ones system, but the user still have to know the victims user ID and whatever else, which makes me think that there's more to this than just set a cookie with the victims data on it.
I have changed all my apps to store cookie logged info encoded [ messThis(usrID) ] then just unmessThis() to read back, this should make it more difficult for a hacker to understand cookie data and therefore re-create it.
Cookie wise, what else can one do to secure cookies? |
I think the meaningful cookie here is the one that is stored to automatically log a user in. But the vulnerability here is not WWF, but everywhere else. Take the Admin account for example. The cookie contains the user_code which is the username ("administrator") with a randomly generated minimum 10 digit hex code appended to the end ("824AAZE76F", for example). So in order to create a fake cookie that will log in someone else as the admin, the attacker must also guess the user_code, not just the username. Even knowing the algorithm that built the hex extension, guessing the hex extension is no trivial task. It seems to me that it is more likely that a hacker will acquire the cookie by dumb luck or by exploiting some other vulnerability outside of the WWF code. Cross-site scripting and a couple dozen other security holes IE, Outlook, IIS, and Windows, viruses, spyware, trojans, man-in-th-middle, packet sniffing, etc. etc. could all be used to attack the PC used by the administrator or the server itself. The hacker is probably not going to tell you how he did it.
However, that made me think of your last question. What can be done to make cookies more secure?
The point of such a cookie is to eliminate the need to log in, so it would be self defeating to require a password of any kind. Even if you encrypt the cookie contents with an unbreakable cipher, what happens if someone else acquires that exact cookie? The trick, I guess, is to make that cookie meaningless if it's used from a different computer and preventing modification or construction of a cookie that WOULD work somewhere else.
If the encrypted cookie contained some information that was unique to the PC that asked for the cookie, the cookie could be made useless anywhere else. But how do you get reliably unique information about the person's PC? You could use a Java applet to pull hardware data from the system, but that probably will not work for a significant number of computer devices in the world.
Instead of storing the user_code, you could store some encrypted representation that includes the user's IP address, that way, an attacker has to decrypt the cookie to get the user_code and encrypt their own fake cookie, or guess the user_code and spoof the IP. This wouldn't change the vulnerability to all the other attacks, but forging a meaningful cookie would be even more difficult.
Or, create an encrypted code to store in the cookie and log the code and the IP address in a separate database. When someone tries to use that cookie, the server will only allow it if it comes from the stored IP.
All is lost if the data is compromised at the server level though.
Topic Options
Post Options
Thanks(0)
