Next, as you are converting to md5, this would only prevent the attack from sqlinjection, but it is recommended to use prepared statements from the PDO.

You would have to treat the user anyway, and there would be problems with that.

Using the PDO would look something like this:

$query = "SELECT * FROM tabela WHERE username = ? and password = ?";
$stmt = $pdo->prepare($query);

$username = $_POST["username"];
$password = md5($_POST["password"]);

$stmt->bindValue(1, $username);
$stmt->bindValue(2, $password);

$ok = $stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

Take a look at the PDO documentation: link

It's worth a look at it.

There is no need to convert or remove anything unless your business rule forces the user to create a password with limitations. This, personally I find it horrible because the more complex the password, the better. This would only discourage the user from creating secure passwords.

But ultimately, it depends on your business model. Suddenly it can be a simple system where it will only allow alphanumeric passwords, or just numerical, anyway. But I do not think that's your case.

Returning to the subject, if the string is compared as a hash, simply pass the already hashed string 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

In your specific case, as I mentioned in the first sentence of this reply, there is 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 like that. In the hash there is nothing to be filtered against SQL Injection.

Can you see where there is something that could compromise a 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:

You can not use the from, select, insert, delete, wherem, drop table, show tables

It is not allowed to use the characters \, -, *, #.

It is not allowed to use spaces at the beginning or at the end.

HTML, CSS, JavaScript tags are not allowed

Finally, escape in quotes (double or single)

All these processes are unnecessary and pointless.

The only useful process would be addslashes () , but I recommend you read this link: #

Also read this: Using the addslashes against SQL injection is secure?