Hacker News new | ask | show | jobs
by awesome_dude 236 days ago
Rule 1.

NEVER trust user supplied data.

Once that rule was broken, any other rules broken became clear to everyone

3 comments

Never trust any data. Even if the data comes from a partner or internal system it could be compromised or defective.
>Never trust any data. Even if the data comes from a partner or internal system it could be compromised or defective.

I don't even call it data anymore. I call it datain't.

You'd think that client side security would be something that we'd gotten over by now.
You'd think but I keep meeting even "experienced" technical leadership that have been at this for a while that there's no way to get around validation and security that's implemented in client code.
I’ve used browser dev tools to regularly add additional drop down options to menus that weren’t present. Huel, for example, only offered 2 or 4 week subscriptions, so I added 3 weeks to it because that’s the frequency I needed, and it worked no problem. 3 weeks later my shakes arrived and every 3 weeks since.
I did something similar on an airline website earlier this year: I wanted to change the date of my return flight and also make it an open jaw (i.e. leave from a different airport than where I had arrived). Changing my flights was included in my original fare, modulo the fare difference. Unfortunately, on their website the input text field for the airport I would be flying out from would get disabled a second or two into loading the "alternative flights search" page, and wouldn't allow me to make it an open jaw. So I fired up my browser dev tools and changed the value of the text field to the desired airport code. Suddenly, I was finding the flights I had been looking for – as it turns out, at no additional charge whatsoever.
My insurance company has different frontend password regex on registration page and on login page. My password passed the registration regex but fails the login regex. In order to log in, I need to manually remove the frontend-side password regex check.
This absolutely boggles my mind. My last insurance company let me create a 20 character PW but limited the password field on the login screen to 16 chars. I didn't think to futz around with the code so I just recreated a less secure password. I suspect many other less technical people either did that too or just called support.

There is zero excuse for that though. 16 chars is just way too short for a proper secure pass phrase, but at least make it consistent with password creation!

Ever since I started using a password manager (a long time ago), I have encountered SO MANY password bugs. But one of the most frustrating issues, is when a website asks you to create a password, but does not tell you what length or characters are accepted. So you have to dumb down Keepass incrementally until it passes. A tedious game.

If your software doesn't accept this password, please change career immediately:

ú¨<¹7®fÍå0Á1n:1}Àº»ê:t]íw´¾ã\B²¸Æþ®M3_ø>$¼ÿa÷mH¦ñ%?6ñE$l#DhqI£«{'Ø"V^c4u

Variant of this I've hit is the phone number validation rules at signup differs from the actual API call to send 2FA texts (or was changed between the time of original signup and login attempt) so I create an account successfully with a Google Voice number and then when I actually need to receive 2FA the message goes into the aether with no error surfaced at any point.
> Variant of this I've hit is the phone number validation rules at signup differs from the actual API call to send 2FA texts

Yeah, this is incredibly annoying, though to be fair, this can be a hard problem to solve. 3rd-party systems often don't tell you what their exact phone number validation rules are or silently update them, and then, to top it off, don't throw errors when validation fails. And more often than not, the 3rd-party system's developers also must have never heard of the Falsehoods programmers believe about phone numbers[0].

Source: I was responsible for adjusting phone number validation for a major ecommerce site in the past.

[0]: https://chromium.googlesource.com/external/libphonenumber/+/...

What's insane is that there are countries where this is considered hacking, even if all you do is change the URL.

somefile-small.jpg -> somefile.jpg

Black hat hacking or white hat hacking? Genuinely curious because a lot of these security write-ups can't happen without "hacking." which may explain why we don't get these security write-ups from folks in those countries.
Somewhere, there is a table with a `frequency` column, storing client-supplied values, and an application happily accepting them as-is.

This is why you normalize your tables and use FK Constraints - you aren’t going to catch all the edge cases in code. Let the DB be the final arbiter of validity, because it’s been tested to hell and back.

Re: Huel, that’s pretty smart. My rate of consumption is fairly consistent (usually 1x/day on weekdays), but occasionally I’ll have one on the weekend, so the given cadences worked for me. I do 2x 12-pack / 4 weeks to hit the free shipping tier.

Did you try adjusting price?
A kid in Hungary was arrested for exactly this (and it was a cheap bus ticket): https://www.bitdefender.com/en-us/blog/hotforsecurity/budape...
It doesn’t seem crazy to me that someone should be arrested for that! It’s stealing. If someone came in my house and stole my property I’d expect them to be arrested, even if I had stupidly left the door wide open.
I am not malicious or willing to attempt theft. Academically though, in an official testing environment, that would be entertaining to attempt.
Yeah I’m not suggesting that you adjust the price, just curious if they were passing price through the client as well.
you can do this on surprisingly many websites, where they include the price in the url they redirect you to, when going to the payment provider, and even then often it is only protected by an md5 hash if it is verified
I love this so much
That’s incredible
> You'd think that client side security would be something that we'd gotten over by now.

Well, we have passkeys. /s

Rule 0: Any networked computer should be considered semi-public. Don't store any information you do not want to be public, or give access to controls that you do not want to be publicly accessible, on a networked computer. There are simply too many vulnerabilities to assume otherwise.
I doubt there are many people in rich countries that follow this rule, given that smartphones are networked computers and people don't want their personal photos to he publicly accessible.
> I doubt there are many people in rich countries that follow this rule

I agree, there definitely are many people who don't follow the rule! And so we get things like this, https://en.wikipedia.org/wiki/2014_celebrity_nude_photo_leak