Password may not contain: select, insert, update, delete, drop • Hacker News Board

Re: Password may not contain: select, insert, update, delete, drop

#171

Post by duskwuff » Sun, Jan 21, 2024, 10:00 PM UTC

Wingy wrote: post #167

duskwuff wrote: post #137

Earlier quoted context omitted.

No, it isn't. If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.

Hashing can be done in a stored procedure. Maybe the organization decided that it's better for the DBA to handle hashing. Nonstandard maybe but not necessarily bad.

> Hashing can be done in a stored procedure. [...] Nonstandard maybe but not necessarily bad.

No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the parameter in a process list. Worse, a stored procedure can potentially be covertly modified to store or exfiltrate the password while hashing it.

Re: Password may not contain: select, insert, update, delete, drop

#172

Post by knallfrosch » Sun, Jan 21, 2024, 10:21 PM UTC

throwawaaarrgh wrote: post #165

Worked on a system like this once. Nobody wanted to fix the actual backend problem so this limitation was a requirement. But I figured that advertising these little "quirks" in the login flow would give hackers ideas, so instead I just added a function to transform the "bad input" into an alternative set of characters that wouldn't have a negative effect on upstream. Since you couldn't view the saved password, nobody…

Until someone builds out your transform

Re: Password may not contain: select, insert, update, delete, drop

#173

Post by mtlmtlmtlmtl » Sun, Jan 21, 2024, 10:22 PM UTC

matsemann wrote: post #56

Can not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..

Hah, I hacked Nettby in school too, good days.

Nettby had no HTTPS, so I did an ARP poisoning MITM and stole everybody's passwords. Then I posted random nonsense from people's accounts and watched the chaos ensue(did no snooping, even 14yo me had a semblance of ethics somehow).

Re: Password may not contain: select, insert, update, delete, drop

#174

Post by pierrekin » Sun, Jan 21, 2024, 10:24 PM UTC

I was made to do this at work also. The reasoning went something like this.

Yes of course we need to properly escape all strings that we render / use parametised queries to avoid injection attacks, however we also need defense in depth, so all fields need to reject code that looks like sql or html.

It was easier to just add this that push back. Sigh.

Re: Password may not contain: select, insert, update, delete, drop

#175

Post by wly_cdgr » Sun, Jan 21, 2024, 10:32 PM UTC

I don't see any downside here. It's just another layer of protection. So what if it's not sufficient?

Re: Password may not contain: select, insert, update, delete, drop

#176

Post by counterpartyrsk » Sun, Jan 21, 2024, 10:37 PM UTC

matsemann wrote: post #56

Can not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..

Interesting, can you explain 'full control'?

Re: Password may not contain: select, insert, update, delete, drop

#177

Post by coolThingsFirst » Sun, Jan 21, 2024, 10:38 PM UTC

mtlmtlmtlmtl wrote: post #173

matsemann wrote: post #56

Can not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..

Hah, I hacked Nettby in school too, good days. Nettby had no HTTPS, so I did an ARP poisoning MITM and stole everybody's passwords. Then I posted random nonsense from people's accounts and watched the chaos ensue(did no snooping, even 14yo me had a semblance of ethics somehow).

Eli5 this attack pla

Re: Password may not contain: select, insert, update, delete, drop

#178

Post by junon » Sun, Jan 21, 2024, 10:41 PM UTC

duskwuff wrote: post #171

Wingy wrote: post #167

Earlier quoted context omitted.

Hashing can be done in a stored procedure. Maybe the organization decided that it's better for the DBA to handle hashing. Nonstandard maybe but not necessarily bad.

> Hashing can be done in a stored procedure. [...] Nonstandard maybe but not necessarily bad. No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the pa…

To be clear, this only improves security if the user reuses passwords.

Re: Password may not contain: select, insert, update, delete, drop

#179

Post by lmm » Sun, Jan 21, 2024, 10:48 PM UTC

civilized wrote: post #141

oliwarner wrote: post #138

Earlier quoted context omitted.

I'm really trying to meet you halfway here but I can't imagine a scenario where I had such low confidence in a third party application that I'd wrap it in input-filtering cotton wool and feel like that was safe enough. A project that both stores plaintext passwords and fails to use parametrisation (something that's been standard practice for over two decades) is untrustable. It's an untenable liability. Maybe I'm wro…

It's not that I think it's acceptable. I'm thinking about how to reduce the harm of people doing unacceptable things that we can't stop them from doing. I would be very transparent about this. I would say this is harm reduction for people who are doing the wrong thing and is a waste of everyone else's time, but we have to do it anyway because software engineering has failed to govern itself as a profession and the go…

Does it really reduce harm? Bypassing something like this should be, like, one checkbox in metasploit. It's like requiring all walls to be wallpapered to make sure no-one spots any cracks in the walls.

Re: Password may not contain: select, insert, update, delete, drop

#180

Post by dmurray » Sun, Jan 21, 2024, 10:56 PM UTC

wkat4242 wrote: post #127

Instead of making sure SQL injection is not possible at all by using proper stored procedures and other techniques, they just limit a few keywords and hope hackers don't come up with something that they haven't thought of like some escaping trick. Yeah that would probably work for a while. Until someone proves it doesn't :P It's not really rocket science anymore to make sure user input doesn't mix with your SQL. This…

> And really if this works in the first place you're storing the passwords unhashed

Not really, your RDBMS probably supports some hash functions so you could be storing them hashed as "UPDATE USERS SET PASSWORD = SHA2($PASSWORD)" which would be vulnerable to SQL injection yet does not store unhashed passwords.

There are good reasons I'd recommend to do the hashing in the application layer instead, but doing it in the DB (with correctly parameterized queries, of course) is not so terrible.