Strawberrynet's privacy insanity

A little while back, I wrote about Website enumeration insanity and how our personal data was being mishandled. In a nutshell, an enumeration risk boils down to a feature on a website allowing anyone to "ask" if a user exists on the website with the site then returning a positive or negative response. For example, to this day you can go to Adult Friend Finder's password reset page, plug in anyone's email address and they'll happily tell you if they'd signed up for a bit of swinger sex action. (Or at least whether their address is on the site, someone else could have entered it into the registration form. Honestly...)

Now all that's bad, but as I pointed out in the aforementioned blog post, it can also be a whole lot worse. I called out a couple of bad examples but chief among those was Strawberrynet who happily returned the following information when entering someone else's address into the express checkout form:

Personal details shown

Yes, that's exactly what it looks like, no this is not after logging in (anyone can anonymously retrieve the same data) and yes, they knew about this. Turns out it's a "feature" and I included multiple quotes from them in the original blog post supporting their design decision. These quotes including justifying the feature due to the presence of SSL, that it's OK because they're PCI DSS compliant, that they'd run surveys and "a huge majority of customers like our system with no password" and my personal favourite:

Using your e-mail address as your password is sufficient security

But it seems that public pressure eventually got to them and sure enough, they acknowledged there's a problem with the process:

Now I was a bit hesitant to take this at face value because they'd made murmurings along these lines in the past but wouldn't you know it, they did actually end up addressing the privacy concerns people had. But it has to be seen to be believed and I'd like to share it here for you, dear reader, in all its glory:

Woah! Wow! Did that just...? I mean the asterisks for obfuscation but then the text boxes and... but... how?! Why?!

Now all I did here was enter a very common female name and wammo! There's all her data - but it's obfuscated. Changing the billing address showed all the data not obfuscated until the secret-ninja-client-script kicked in and hid it all from prying eyes. Very sneaky! But of course the data is still there in the fields anyway, however... those first and last names aren't really befitting of a woman now, are they? But anyone can edit the billing address so clearly someone has taken a few liberties with the poor girl's details.

I took a brief look at their HTML source in an attempt to better understand their thinking but, well, yeah:

It's one of those cases where a very distinct pattern emerges that tells a very sad software development story, a story of someone's brother’s cousin's aunt's dog doing a bit of web dev and offering to help out. In this case though, it's helping out to build an international ecommerce platform targeting customers across the globe. That actually makes things a bit more interesting because in May next year, that will put them clearly in the sights of GDPR and European Data Protection Authorities don't tend to have much of a sense of humour about these things. Maybe a stiff penalty will finally knock some sense into them...

Security Privacy
Tweet Post Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals