Design your own security vulnerability #1

The first in probably an even more occasional series... None of these are new. But people keep making the same tired old mistakes.

We begin, as ever, with the best of intentions. As part of our business, let's store some customer data by customer ID, where customer ID is a numeric key on our database of customers. Most databases will happily generate this for you and increment it by one when you add a new customer.

Let's have a web page so the customer can see his own data, say at https://my-safe-data.biz/customer/NNNNN where NNNNN is the customer ID. Fine and dandy. No-one but the customer and us know his ID, so he's quite safe. We can just pass that ID to the database, ask it for the data for that customer, and present it. Don't need to password protect it, because the ID is its own password, right - no-one knows anyone else's customer ID, do they, surely??

Wrong.

You don't have to know anyone else's customer ID. Just make an educated guess on how they're generated.

Enter J Random Cracker, who just happens to have seen one of our URLs because he's a customer. "I wonder", they think, "what happens if I change my customer ID by 1"...

"Oh look. Someone else's records." An hour and a bit of scripting later, and they've pulled out LOTS of records to which they have no right.

"But", you say, "no-one would be that stupid, would they?"

Well yes. They would (and yes, just one of many examples, before you ask).

One easy fix is to require a login before you can access your own data, but that opens more potential vulnerabilities. Of which more later.

Another is to use a different method of generating customer IDs.

Same applies.