We are given a concrete scenario here which covers user login. And that described scenario is only susceptible to that NoSQL query injection risk because passwords are stored in plain text in the database, which is a big security no-no and absolutely worth pointing out.
When hashed passwords are stored in the database then we are also forced to hash the user-provided password from the login request. In the given example that effectively defuses any NoSQL query injection risk. Any injected query operator would turn into a garbled mess before being used in a query.
Personally I would be OK with discussing the NoSQL injection vulnerability if the scenario was not based on an already flawed premise. No one should be storing passwords in plain text.
What if you reversed it? Use the injection vulnerability in the username, and guess from a list of common passwords. If any user is using a common password, it should authenticate you.
But another flaw with using "findone" for authentication like this seems to be that you can't use a salt. You should first select the row (or blob? IDK NoSQL) matching the username, and then compare the hashed+salted password.
Good point. I turned a blind eye towards the user name since unsalted hashed passwords are also not good enough security-wise due to rainbow table attacks on leaked password hashes. As you point out passwords should be individually salted, so two hashes of the same password are not the same.
The required lookup of the user record for the password's salt hopefully also makes a NoSQL injection attack against the user name infeasible. I would assume that a proper login implementation only looks at a single result from a query, and does not loop over them until it finds a proper match.
One way is to match against email (or username or what have you), and then compare the salted hash to the password - outside of NoSQL-land.
Otherwise, what your query is really saying, is that a user could potentially have multiple accounts under the same name, with different passwords.
But yeah, the scenario the author presented the stuff with is flawed. But the point still comes across: Never trust user input. With SQL, protecting yourself from injections is pretty simple. NoSQL seems a bit more tricky
Yes, agreed. And JavaScript makes it a little too easy to mess user input validation up since it's so weakly typed. Maybe NoSQL is not entirely to blame here :-D
I think a JavaScript validation library could have been mentioned in the article too. I'd prefer having some proper error feedback from the server when I'm passing in wonky request payloads (by accident or on purpose).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No it doesn't. This vulnerability affects any where clause.
We are given a concrete scenario here which covers user login. And that described scenario is only susceptible to that NoSQL query injection risk because passwords are stored in plain text in the database, which is a big security no-no and absolutely worth pointing out.
When hashed passwords are stored in the database then we are also forced to hash the user-provided password from the login request. In the given example that effectively defuses any NoSQL query injection risk. Any injected query operator would turn into a garbled mess before being used in a query.
Personally I would be OK with discussing the NoSQL injection vulnerability if the scenario was not based on an already flawed premise. No one should be storing passwords in plain text.
What if you reversed it? Use the injection vulnerability in the username, and guess from a list of common passwords. If any user is using a common password, it should authenticate you.
But another flaw with using "findone" for authentication like this seems to be that you can't use a salt. You should first select the row (or blob? IDK NoSQL) matching the username, and then compare the hashed+salted password.
Good point. I turned a blind eye towards the user name since unsalted hashed passwords are also not good enough security-wise due to rainbow table attacks on leaked password hashes. As you point out passwords should be individually salted, so two hashes of the same password are not the same.
The required lookup of the user record for the password's salt hopefully also makes a NoSQL injection attack against the user name infeasible. I would assume that a proper login implementation only looks at a single result from a query, and does not loop over them until it finds a proper match.
One way is to match against email (or username or what have you), and then compare the salted hash to the password - outside of NoSQL-land.
Otherwise, what your query is really saying, is that a user could potentially have multiple accounts under the same name, with different passwords.
But yeah, the scenario the author presented the stuff with is flawed. But the point still comes across: Never trust user input. With SQL, protecting yourself from injections is pretty simple. NoSQL seems a bit more tricky
Yes, agreed. And JavaScript makes it a little too easy to mess user input validation up since it's so weakly typed. Maybe NoSQL is not entirely to blame here :-D
I think a JavaScript validation library could have been mentioned in the article too. I'd prefer having some proper error feedback from the server when I'm passing in wonky request payloads (by accident or on purpose).