Back when I developed ticketing software for events, the clients would complain that I made the ticket ID too long. I feel vindicated today.
Via a post to the Torcamp mailing list (from Stephen, last name left out to give some semblence of after-the-fact privacy,) I found out about an email campaign being run for Primus Canada. It’s got all those slick bits that marketers love: you get a personalized link that shows a video WITH YOUR NAME IN IT! Wow! And better still, you get to send customized videos to your friends! Viral wow!
The only real problem here is that instead of using, say, a GUID or some other really big identifier in the personalized URLs, the company used an integer. A few quick tests confirm that it’s a sequential integer.
Let’s spell this out: Primus has provided their customer list of names and emails to anyone who can edit a URL.
So what’s the exposure? In about 3 minutes of entering higher and lower IDs in the URL, I found a consecutive range of about 144, 657 IDs. I didn’t try every number in that range (you can be sure some scrapers are doing that right now, somewhere on the internet) but given the overall naivete of the URL scheme I’m guessing the range is unbroken.
What’s more, it’s highly possible that there are other ranges in there from other database loads.
Picking an arbitrary starting number for your consecutive number range is not a realistic security measure. In my ticketing days mentioned above, the exposure would have been counterfeit tickets which might or might not have been caught at the gate (there were secondary measures like the customer’s name on the ticket matching the scan.) Here, I can pretty much guarantee that a lot of Primus customers just got added to a bunch of spam lists.
So, for developers out there (or marketers with half a brain that want to test their dev team), what’s a better way to do this? As I suggested, a GUID would work better – it’s a really big number that’s harder to guess, but not impossible, and the more names in your database, the more hits, so I’d add the customer’s actual email address (or a tokenized version of it) to the URL as well – this is an email campaign, and it’s not like people will be typing these URLs in anyway, so there’s not much harm in making them bigger. The email token’s probably overkill, but this way the only way an attacker is going to see the email address is to know it in the first place.
Oh, and added bonus: if you view the source of the landing page there’s a link to the privacy policy and the terms and conditions. They’re commented out.
Update: Andrew Loius has even more gory details over here.
Update 2: The site’s been pulled (like, hard down, 404 not found, Gordon Ramsey style “shut it down.”) Hopefully they’ll resolve this properly and recover somehow; it’s not a bad campaign, just an unfortunate deployment.
Leave a Reply