The problem here is that I hear time and time again about how some app was hacked bacause the cookie was stealed, how the heck so?
The other part of the problem is that I can't re-create this hack, therefore can't effectively secure against it, what I'm doing, is, securing based on guess work, if someone was to create a fake cookie he would need these variables with these values, so lets get those values all scrambled up and variables with less meaningful names of what they do.
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.
theSCIENTIST wrote:
Comparing against the IP, defies the purpose of using cookies to auto-login, since many ISPs still assign IPs dinamically, not fixed, maybe when IP v6 comes into place, ISPs will then assign a fixed IP to all customers, which in it-self should allow us developers to go into many new directions.
Good point. I've been spoiled by the static IP for so long, I forget there is the other world out there.
Tell me then another way to check if a user has permission to view a page? Even if you use Session variables that's a cookie also, the only difference is that it is destroyed after it's timeout or browser closure, as for the auto-login, I can live without it, but for a forum app, most users like it.
JJLatWebWiz wrote:
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.
I'm going to have to really understand this attack, preferably re-create it. I use cookies in one way or another and feel kind of stuck without them, I remember reading a few years back that cookies are bad, and here we are now still debating the issue, this time the concern is even bigger.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum
Web Wiz is the trading name of Web Wiz Ltd. Company registration No. 05977755. Registered in England and Wales.
Registered office: Web Wiz Ltd, Unit 18, The Glenmore Centre, Fancy Road, Poole, Dorset, BH12 4FB, UK.
Prices exclude VAT at 20% unless otherwise stated. VAT No. GB988999105 - $, € prices shown as a guideline only.