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.)
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.
How to say you’re vulnerable to code injection without saying you’re vulnerable to code injection.
Maybe they filtered those strings to be safe, and put the notice there to answer the invertible “why won’t it accept my password” queries.
It’s a shitty password engine. But not necessarily uncleansed
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.)
I don’t know, maybe they saw that classic XKCD comic and now they’re thinking “hahah, I’m wise to your tricks, ya little shit”
Are they vulnerable though, if they already exclude it at the user input?
I yet have to learn SQL and is there a way to allow passwords with '); DROP TABLE… without being vulnerable to an injection?
nevermind i googled it, and there various ways to do so
Good old Bobby Tables
I noticed that upper case select, drop etc are not prohibited.
Poorly implemented user input filters are not a valid solution to being vulnerable to injection.
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.
At best, it means they’re storing your password instead of just a salted hash. And that’s horrible.
This still smells though. Why is the raw, plain text password string getting anywhere near database queries in the first place?
I doubt it is. they probably have a WAF that blocks these strings though and didnt want to bother reconfiguring it