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 composition

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.

Before Parameterized SQL was a thing, sanitizing was the thing. There’s a lot of escape_string() type of methods out there.

Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though

Could you describe it conceptually how they do it?

The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main...

I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound

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.

Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work

When you can use approach which fundamentally prevents SQL injection?

I didn't say you should, I am just noting that there's no complexity in the solution required, it's simple and yet still many people don't do it.

That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.

Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.

look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.

I didn't say I don't use parameterization, and I still haven't heard what the difference is between the old style escape methods and the quotes I mentioned, just you being salty :)

Thinking about it, it can also be that the input is sanitized a little too much.

Imagine the user uses "select_mypassword" as a password. The sanitizer kicks in and silently mangles your password, resulting in another password being stored than the one you entered, effectively locking you out. Or maybe it just fails with an obscure error because some overzealous countermeasure triggered. I wonder what using the EICAR file as a password would do btw.

Also, while the password may be stored properly (hashed), the password still transits in plaintext before it is stored or verified. So even with hashing, you can still be vulnerable to injection.

Presumably you would apply the same sanitizer at login time to whatever password the user enters. If the input is the same and the transform is the same then the output will be the same.

Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.

What may happen is that every step is siloed in some way and every team assume the others are monkeys on typewriters. From a security perspective, it is not necessarily a bad thing, but it can make the user experience terrible.

For example, I may write some piece of software that refuses to write files with spaces in them, because I suspect that later on, some shell script will process them and it is very common for poorly written shell script to break with spaces in file names. But it may turn out that unexpectedly, the people who write the back end are competent and deal with spaces just fine. But on their side they may expect me to be be the monkey and say, avoid replying with Unicode characters, assuming my code will break if it gets something that is not an ASCII printable character.

So in the end, the user will have neither spaces in file names nor proper Unicode support, even though the software wouldn't have any problem with that if two team properly communicated and didn't think of each others as monkeys.

This relies on a false assumption that the sanitizer is static.

If we're to continue with this thought experiment in doing the dumb thing. Clearly you would version your sanitizer and store which version you used when saving the password. That way you can ensure the same version is used against future user inputs.

> 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)

That is correct.

The client sends the encrypted (via HTTPS) but not hashed password to the server, both for changing your password and checking your password. So the server receives the password in plaintext but shouldn't store it.

Whatever the client sends to the server, an attacker can send too.

You're not the first to come up with that exploit-

https://en.wikipedia.org/wiki/Pass_the_hash

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.

If you're using a third-party reverse proxy, then the third party will have access to the user's password. What's the simplest way to prevent the third-party from knowing the password? Would adding an encryption layer between the user and the actual website owner be both feasible and sufficient for the average website owner?

Don't use reverse proxies you don't trust

How could the validation layer be affected by the presence of these substrings?