How can you break this SQL injection protection
This question is not about creating a viable alternative to proven injection prevention features, but how to argue with people who see no shortage of their home injection prevention code!
I'm trying to point to a colleague, but it seems that his "solution" for SQL injection seems to me to be safe enough.
It clears up the request by doing
$query = $_POST['username'];
$look = array('&', '#', '<', '>', '"', '\'', '(', ')', '%');
$safe = array('&', '#', '<', '>', '"', ''', '(', ')', '%');
str_replace($look, $safe, $query);
And then comes with the login
"SELECT * FROM users WHERE username = '" . $query . "'
AND password = '" . md5($_POST['password']) . "'";
I'm trying to get it to use PDO or equivalents, but how could you break this protection? I don't have an answer and it really eavesdrops on me because I can't explain to him how insecure it is and why it shouldn't be done this way.
source to share
This is a really horrible way to "avoid" with a lot of pitfalls, and only a few of them
- This code actually changes data on the assumption that the only output medium will be HTML. From my 15 years of experience, I would say that this is not true. Changing your data is always bad, it will lead to inconsistency and back pain in the future. One is that this "formatting" will be multiplied with each edit, making ampampamp a simple quote.
- Injections through numbers.
- Injection via identifiers.
- second order injections.
... and much more.
The strict rules of this site prevent me from using the correct words for such "protection", but feel free to introduce them yourself.
source to share
While this probably covers most of the typical SQL injection issues - there are a few known issues with the use of multibyte character sets and certain locale settings on the server.
However, this is not just escaping - it is actually changing the data that is being entered into the database. Just add slashes if needed, or use one of the built-in escape methods such as mysqli_real_escape_string
when entering data and htmlentities
the like when redisplaying it in the browser. This ensures that what you store in your database will always be entered by the user - unless you have a reason to do so.
Better yet, when in doubt, use prepared statements and associated parameters. Then you are completely protected from SQL injection.
source to share