3 ms·
It's a second stage SQL injection, and it's very serious. Here's a contrived example: At the user creation page the malicious user wants to get admin access.
by ifoundthetao 10y ago
It's a second stage SQL injection, and it's very serious.
Here's a contrived example:
At the user creation page the malicious user wants to get admin access.
They have their username be: admin' --
They do this because they are betting on a user named 'admin'.
Their password is: alwaysSanitizeInputs
So, a user is created named "admin' --".
Now, they go in to update their password.
The DB nicely pulls out their username, "admin' --", and it says:
UPDATE users SET password = SHA1('newPassword') WHERE username = 'admin' -- AND password = SHA1('alwaysSanitizeInputs');
So what happens? Well, the user "admin" now has a different password, and the Malicious user knows what it is. That's why you still need to sanitize.
- themihai 10y agoI don't think the solution is to validate it everytime you use that data/value. I fail to see how you mitigate the issue with the second validation. You have duplicate records so hoe you fix it? Shouldn't you check duplicate sccounts on sign up?
- ifoundthetao 10y agoYou're still thinking too small. It isn't about validation for duplicate accounts, and by the way, this gets past that duplicate account validation, because "admin" is different from "admin' --" You get around it by parameterizing your queries, and not blindly trusting data that comes from the database.