Prepared statements, mostly. You define the query using variables, turn that query into a language-dependent object, assign values to those variables, then execute the statement. The values will be passed verbatim, without any parsing.
Or, since we're talking about a password, you could encode or encrypt it before inserting it into the query string. The fact that the website could be negatively affected by phrases in the cleartext password is very concerning.
If they're trying to protect themselves from code injection by rejecting certain user input like that, then they don't actually know how to protect themselves from code injection correctly and there may be serious vulnerabilities that they've missed.
(I think it's likely that, as others have said, they're using off-the-shelf software that does properly sanitize user input, and that this is just the unnecessary result of management making ridiculous demands. Even then, it's evidence of an organization that doesn't have the right approach to security.)
That's not how it works. The code always has access to the submitted plaintext password. It's salted and hashed after it's verified for complexity. The complexity verification can even be done in JavaScript.
Some of the strongest and easy to remember passwords are just a few words strung together with a few numbers.
For example: Simpsons7-Purple4-Monkey1-Dishwasher8
Just remember "Simpsons Purple Monkey Dishwasher" and "7418". You're probably never going to forget that and I just tossed it into a password strength tester and it said it would take about 46 billion years to randomly guess it.
Now remember these types of passwords, all different for different services. It's not a realistic expectation. Password managers are a must nowadays if you want to protect your accounts. But these types of passwords are also easier to type out.
Password strength checkers are taking an approach that's naive for this case. The actual strength depends on the size of the dictionary and the number of words you randomly choose out of it.
Bcrypt has a length limit of 72 characters, so very long passwords generated this way can be silently truncated. Developers can avoid this problem by running sha256 on the input before giving it to bcrypt, but that isn't common.
If the structure of it is known it becomes much faster. Word+single digit^4 isn't all that hard.
For the vast majority of purposes, it'll be fine. And certainly as long as that particular structure isn't commonplace, it won't be easy to guess anyway. But password strength testers don't consider that - guessing "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" randomly also takes billions of years, so they can give a bit of a sense of false security.
The fastest super computer at the moment apparently sits at 1.1 quintillion Hz. Or 1.1 billion billion.
If that computer could make 1 guess every clock cycle it would still take it over 4 years (167957820891293697014400000 / 1.1quintillion = ~52 months ) to run through all possibilities.
Now that is a very fast computer, and we haven't included the possibility of various numbers of words, different delimiter, or where and how often numbers appear. So unless you've really pissed off the US gov I don't think you have to worry about it.
There's a reason passphrases are the currently recommended way to generate secure passwords that are hard to guess but easy to memorize/type in.
I also tweak my base password based on the site. One site hack could lead to all your passwords being compromised no matter how long it is. Sure someone might be able to figure out the pattern if they analyzed it manually, but most hacks try to break into accounts en masse and they're not going through passwords one by one.