I hear you.  It's a serious concern because of the number of people reporting it.  I periodically spend time exploring different methods of attack using cookie forging, and I'm fairly comfortable saying that almost all cookie based exploits are not a weakness in the target app, like WWF.  If I create a web site that steals cookies or compromise your machine by sending an email with a cookie-napper, I haven't exploited WWF.  I've taken advantage of another vulnerability to use against WWF.

 

It might be a good idea to encode more information into the cookie to obfuscate the meaning, but there are a couple reasons why that might not fix anything.  First, if it's not encrypted with a decryption password unknown to the hacker, it's going to be a simple thing for the hacker to encode his own forged cookie.  Second, if the attack is a "stolen" cookie, then assume the cookie data is encrypted with an unbreakable cipher but the attacker steals your cookie, how will the web app determine that the cookie was stolen?  If it's just decrypted and decoded, it didn't do anything but obscure the meaning.  But a hacker will always know the meaning unless every users of WWF modifies the program to scramble the meaning.  Even then, figuring out the meaning probably won't take too long.

 

You should assume that the hacker always knows what values are scrambled in the cookie and always knows the meaning of every variable.  And unless you understand the attack, then you're counting on luck that your fix will work.  Maybe a more secure solution is to prevent cookie-based login for admin accounts.

 

I could be wrong.

 

 

Good point.  I've been spoiled by the static IP for so long, I forget there is the other world out there.

 

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.

 

Not to say that WWF is not a vector for attack, it absolutely is one way to escalate access to a site and server.  Especially if WWF has not been installed and configured in a secure method.

 

I recently had one of the sites I maintain get hacked.  I was using an older version of WWF that didn't yet have the upload capability, yet the hacker still chose to cause damage only to the forum.  I suspect they do that because forums are the most visited part of most sites that have forums.  I found a hacker tool planted in the forum folder.  But, knowing that WWF could not have been used to upload the hacker tool and that I had no anonymous FTP account, I began searching for the origin.  With only the anonymous IIS user account, I was able to navigate to the root of the c: drive, see all files there and in the windows and system32 folders.  I could download, upload, and delete files.  I could get to all other sites sharing the same server and modify the contents of their folders.  Still as anonymous, I could download the forum's MDB file, make changes, including changing the password, then upload the changes replacing the original MDB.  Basically, there was almost nothing I could NOT do.  I could have utterly destroyed the entire server.  I suspect that the hacker dropped his utility on my site from another site hosted on the same machine.

 

If the hacker will give you more details, we'll all be better off.  My feeling is that a real hacker would not talk to you at all, while a wanna-bee, script kiddie, is probably mis-directing you.

 

Make sure you follow the WWF installation directions to the end to make your data as secure as possible.  Keep incremental backups of the data.  Periodically check the Admin email address and password hash & salt for changes.  Ask your host if the "Everyone" account can read the root of C:, C:\Winnt; and C:\Winnt\System32.  Your host might not even admit it, but most hosts have the default user rights still and are at extreme risk.

 

My 2 cents.