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.
"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
When you can use approach which fundamentally prevents SQL injection?
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
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.
Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.
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.
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.
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.
Parameterize the SQL on the server instead of concatenating strings.