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:
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:
Thank you for your feedback. We understand your concerns, we’ll launch a new checkout flow to improve the user experience in coming 2 wks.— Strawberrynet (@Strawberrynet) May 2, 2017
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 @gmail.com 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...