There is no need to convert or remove anything unless your business rule requires you to create a password with limitations. This, personally I find horrible because the more complex the password, the better. With this, I would only be discouraging the user to create safe passwords.
But anyway, that depends on your business model. Suddenly it can be a simple system where you will only allow alphanumeric passwords, or only numerical ones, anyway. But I don’t think that’s your case.
Returning to the subject, if the string will be compared as a hash, simply pass the string already converted to hash in the SQL query.
Let’s see in practice:
$senha = "'; delete from users; --"; // aqui temos uma injeção sql bem grosseira.
$query = "SELECT campo FROM tabela WHERE senha = '".$senha."'";
This will produce a query with an SQL injection:
SELECT campo FROM tabela WHERE senha = ''; delete from users; --'
Simple and logical way to solve
For your specific case, as I mentioned in the first sentence of this reply,
no need to filter SQL injection.
An MD5 hash does not contain characters that could compromise the query with injections.
I’ll show you the reason with a simple example:
$senha = "'; delete from users; --"; // aqui temos uma injeção sql bem grosseira.
$query = "SELECT campo FROM tabela WHERE senha = '".md5($senha)."'";
The query produced will be:
SELECT campo FROM tabela WHERE senha = '9dc8014996ca2a4a67e2448a6c9821e0';
Simple as that. In the hash there is nothing to be filtered against SQL Injection.
Can see where there is something that could compromise an SQL query in this string 9dc8014996ca2a4a67e2448a6c9821e0
?
Let’s evaluate the function you posted in the question:
function anti_injection($sql){
$sql = preg_replace(sql_regcase("/(from|select|insert|delete|where|drop table|show tables|#|\*|--|\\\\)/"), "" ,$sql); // remove palavras que contenham sintaxe sql
$sql = trim($sql); // limpa espaços vazios
$sql = strip_tags($sql); // tira tags html e php
$sql = addslashes($sql); // adiciona barras invertidas a um string
return $sql;
Translating:
It is not allowed to use the words from, select, Insert, delete, wherem, drop table, show Tables.
Using the characters is not allowed \, --, *, #.
No spaces allowed at start or end.
Using HTML, CSS, Javascript tags is not allowed
Finally, make an escape in quotes (double or single)
All these processes are unnecessary and meaningless.
The only useful process would be the addslashes(), however, I recommend that you read this link: addslashes is the basics for security?
Also read this: Using addslashes against SQL injection is safe?
It is the second time I see this "anti Injection" here on the site. This code has no foot or head, and I remember that even in the original post, it has more criticism than anything. Even, at the time, the author himself commented that he did not know exactly what he was doing. Suggestion: delete this. PS: the mysqli extension already has its own function for this, is the
mysqli_real_escape_string
, or better than that, you can make a query prepared, and pass the values by bind. Update: I found a third mention here: http://answall.com/questions/74081/– Bacco
So Bacco I studied the function and understood it yes, all the treatment made in it has sense: CLEAR THE EMPTY SPACES, REMOVE SQL COMMANDS, REMOVE HTML AND PHP TAGS AND FINALLY BACKSLASH If the person places inappropriate items that characterize SQL Injection will not login and will not succeed! The big detail for me would be the asterisk, but the MD5 would be no problem :)
– Gabriel Garcia
There is no sense in it. It is no problem for you to have SQL commands in a string, as long as it is properly escaped. Banning certain texts is a completely senseless solution. I won’t insist too much, but I hope that in time you will understand that this is beyond unnecessary, sooner or later will cause problems.
– Bacco