Trusting cookies and shopping carts

merlyn on 2002-12-03T15:14:43

About once a week, I'm seeing a BUGTRAQ note on some exploit of a shopping cart based on manipulation of cookies.

While most of these probably aren't Perl-related, I'm just amazed at how many so-called "web programmers" don't understand that trusted state should not be stored in cookies. I ranted about this in a column of mine and even provided the two-dozen lines of code required to manage cookies properly and securely.

If Netscape had only embedded a unique serial number in each browser, and not invented cookies, people would have done The Right Thing. {sigh}


I don't think that serial numbers would help.

Ovid on 2002-12-03T16:15:42

And merlyn writes: If Netscape had only embedded a unique serial number in each browser, and not invented cookies, people would have done The Right Thing. {sigh}

While that's an interesting idea, I see a couple of problems. The big one is obvious: everyone is going to scream about their privacy and they would be right. Can you imagine the field day that spammers would have once they realized they could map the serial number to a set of preferences and a name? Our government has made it clear that they don't give a damn about our privacy when it comes to commerce (and campaign contributions), so I doubt there would be help from that quarter.

The other problem would be the sharing of serial numbers. Crackers would try to break the algorithm or at least write code that creates valid serial numbers (and given Netscape's history, that wouldn't be too hard) and then the cracker would create a tool that would send whatever serial number they wanted. You would have crackers hit site after site with another person's serial number until they hit a site that automatically logged them in. Programmers would still be creating the same stupid security holes; we'd just have different twists on them.

And while we're on the subject of security, one of my favorite pet peeves: I can't stand programmers who design shopping carts using hidden fields to hold the price. It can be done safely if one is careful to embed some sort of anti-tampering device (like a MD5 hash), but despite having heard of that, I've never seen it actually done.

Re:I don't think that serial numbers would help.

brentdax on 2002-12-22T19:06:02

It can be done safely if one is careful to embed some sort of anti-tampering device (like a MD5 hash), but despite having heard of that, I've never seen it actually done.
So then a clever hacker will just MD5 the new price. That worked well. :^)

The bottom line is that you have to have some of the data be held in a trusted store, so you might as well avoid the need for checking for tampering by just using a product ID of some sort.

Re:I don't think that serial numbers would help.

Ovid on 2002-12-22T20:58:47

The MD5 hash works by having a secret key of data kept on the server. The hidden fields are used with the secret key to ensure that creating a new MD5 hash is non-trivial. The hacker would likely be forced to brute force the key. This would be more difficult than a typical crack because there could be many hidden fields and the attacker would have to try different combinations of them. That, combined with a random enough secret key would make the MD5 hash relatively secure. I guess I should have mentioned the secret key up front :)