Australia and New Zealand are insanely careless with personal data. I was shocked when I was asked to write my credit card details, including cvv, on a piece of paper in a beachside surfboard rental shop
Australians are very lax on human rights, including the right to privacy.
Pine Gap is the world’s largest network tap, after all, invalidating the human rights of close to 2 billion people, every single second of the day.
The nation was bred to be so compliant. Australians are not afraid of licking boots if it means cheap avocados can be smashed.
Yeah, no. That's someone who is lazy and not following our rather comprehensive credit card regulations [0]. PCI DSS is required by both VISA and MasterCard, who are the only one's approved by said regulations. CVV storage is not permitted.
If you reported them, chances are, the business would be shut down.
[0] https://www.rba.gov.au/payments-and-infrastructure/payments-...
That is neither standard nor normal.
Hotels always ask to physically take my credit card, random maintenance guys ask to access my apartment without a heads-up from the landlord. It's seen as normal, but in my book it's a bit careless.
I agree that Australia could improve a lot but hotels will take a credit card scan at every country I've been to. In many other countries they also take your passport away and you wait a while to get it back.
> .. Australia could improve a lot but hotels will take a credit card scan
I've not had this done to me in Australia since late 90s early 00s. These days all it takes is a simple tap (or chip swipe) to put a temporary Hold[0] that's released on check-out (or next day).
Of course hotels take your CC, how else are they supposed to charge it? And maintenance men accessing your home without a heads-up is very much illegal and not commonplace.
They're not supposed to write the details down, which is what this person was referring to.
In Asia, they quite often take your CC details and enter it into a text field in their own system in case they need to process it later, including the CVV. Sometimes they're writing it down on paper.
They're not entering it into a PCI compliant system where the digits are masked.
Perhaps. From a distance (physical, social, or both) local norms of behavior are often non-standard and abnormal.
It's certainly not the norm in Australia, nor have I come across that in probably the last 15 or so years. Running your credit card through the terminal to place a hold on funds is done pretty much everywhere. I'm sure there's a few crusty old operators out there doing things the old way.
This isn't normal in Australia or New Zealand, at a national or a local scale. But you can't draw conclusions at a national scale from a local interaction, either way.
Had the same experience in Namibia in 2022. First I should sent them my credit card stuff via mail. Then via a website which looked like it would automatically write my data to a mail and send it to them :D.
I used a freshly generated virtual credit card with payment amount +20$ as a limit (just to be sure).
Everyone dogpiling on you is incorrect. This has been my experience as well.
I swear half my job these days is helping australian businesses retroactively purge themselves of plaintext card data.
I have seen some shit man.
That reminds me of all the SQL injection vulns that we used to blame on PHP. As PHP becomes less popular, and the same/similar vulnerabilities remain, I realise it's more just bad practices (though ~2000-early 2010s PHP really was pretty rough when it came to creating those holes, but that might just be a function of how popular it was!)
Nice work on finding it :)
PHP was blamed for a good reason: for a long time it did not by default support prepared SQL statements. You could install the mysqli extension to gain such support but that was almost never available on shared web hosts.
And every tutorial you could find on how to use PHP with a database was a tutorial on how to add SQL injection to your site.
That was the bigger problem, IMO, in that even once PDO existed and the MySQL extension was "fixed" to have prepared statements, so much of the documentation still did it wrong.
And yet similar classes of bugs still pops up today, even with what I would've assumed to be safe defaults? I'm guessing its non-standard databases or DB clients or something?
This case is more just a pure lack of sanitisation, but it's fascinating to see in 2025 still :)
At least they cared. I found an enumeration attack on an Australian referral service where phone numbers were keys and it returned way too much personal information. Responsibly disclosed numerous times, LinkedIn contacted employees. Not even acknowledged and at last check, still open vulnerability.
The sad thing is, that at some point they truly get exposed (big leak) and your name might come up because they have nobody else to blame. I wish you the best and hope you have lawyer insurance.
Does this api allow me to enumerate the users (by phone number) using the service? That would seem to be bad as well. I. guess that it depends on what their fix was.
If this really was the first api request made by the app, and it has a serious vulnerability, then the omens are not great for the rest of the api calls either.
Be super careful with this, you had innocent intent, but that doesn’t mitigate the fact that you potentially broke the law (and regardless of whether you did or not, that won’t stop feds busting in the door). Some places will take reports like that gratefully, others will do everything in their power to make you out to be the bad guy.
>I did some research and found that the app did infact have a responsible disclosure policy which at that point, I was happy to continue forth.
Looks like he did some research before.
On the other hand
>On day 2 I awoke and began by finding some form of contact details, information was somewhat sparse but I managed to find a phone number.
Doesn't a responsible disclosure policy contain contact infos on where to report usually?
Weirdly enough... not always.
When it comes to random companies running their own VDP vs. hiring it out, it can be less than standard despite there being lots of resources on setting it up. I've seen ones that only include a phone number, the email address listed doesn't exist anymore, etc.
Others have had to even get to the point of contacting an executive via LinkedIn despite there being a VDP page / security.txt.
No, they did not in any way break the law. As they wrote themselves:
> I did some research and found that the app did infact have a responsible disclosure policy which at that point, I was happy to continue forth.
Under New Zealand's Crimes Act, all unauthorised access is illegal. This has been used in court to cover places where someone was not pre-approved, rather than just a policy that gives an implied acceptance. It has also been used where someone has accidentally gained access via insecured systems.
I would not be so confident in stating that they did not break the law.
Any half-decent VDP will have a safe harbour clause. Otherwise ot isn't a true VDP but rather just contact details.
So far, the courts have ruled that you need to be specifically approved, by name, before any works begin. There is no safe harbour here. Your policy does not overrule the law. You need a pre-existing relationship with the company, before you begin to look for vulnerabilities.
Honestly cool to see a story like this where the punchline isnt "They never fixed the bug" or "They sent goons after me".
Hmm. Notably Farmers NZ recently had an extended unplanned outage, and has a 4 star app
by default, make the thing return a 400 Invalid Request for any request that did not fit exactly what you are expecting. That at least lets you focus on ensuring the data that you are expecting is sane/valid/safe. Undocumented features will eventually bite you, and are loaded footguns, especially if your QA team doesn't know about the undocumented features.
to think someone thought that api was a good idea and got all the way to deploying it, yikes