Live data from Hacker News

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

id.uni-lj.si

11–20 of 254 posts

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

#11
post #6

Earlier quoted context omitted.

Actually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree compositi…

Parameterized SQL is your friend here.

Yeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.

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

#13
post #9
post #3

Optimistically, perhaps this requirement stems from an overzealous WAF

That, or some poorly architectured "framework" or toolkit. Others in the comments see this as "proof" that the application has poor security. I don't think we can draw that conclusion. We can, however, draw the conclusion that some part of the stack is poorly implemented.

I mean, this is a gross misunderstanding of how user input makes its way into a database safely. If you're putting out error messages like this it's a giant red flag.

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

#14
post #7

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.

Is it a slow sunday for me or... If you hash the password on the client and send the hash then hash is the password. And if you then have, for example, a DB leak with username and hashes, you don't need the password anyway because you can just send the hash and log in? (but then it's sunday and I need more coffee so I may be wrong)

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

#16
post #7

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.

[deleted]

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

#17

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

Actually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree compositi…

You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.

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

#18
post #10

Did someone have a Bobby Tables moment? https://bobby-tables.com/ In Oracle, you can't use a bind variable in setting a password on an account, so SQL injection is a more significant risk. I wrote some JavaScript and pl/sql to address that.

I hope that javascript filter runs on the server and not on the web browser...

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

#20
post #7

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.

Don't hash the password on the client. That just changes the password to the hash of the password.

Parameterize the SQL on the server instead of concatenating strings.

Post reply on HN