En caso de evitar que se produzca SQLi, agregué este tipo de comprobación:
preg_replace("#([\[\]\|\.\,:'])#s", " ", $data);
Este reg_ex debería reemplazar todo doloroso, porque la consulta principal se ve como
SELECT line FROM text WHERE tid LIKE '%{$data}%'
Puse varios apóstrofos codificados tratando de evitar mi cheque y parece una buena protección. ¿Qué piensas?
No hay razón para implementar su propia lógica de desinfección en 2016. Como señala Aria, solo puede usar mysqli_real_escape_string si desea desinfectar. La clave aquí es que este NO es un medio 100% efectivo para prevenir SQLi.
La forma correcta sería utilizar la biblioteca mysqli para parametrizar consultas, porque esto hace que la inyección de primer orden sea imposible. Es posible que veas muchas recomendaciones para usar DOP para hacer declaraciones preparadas. Es importante tener en cuenta que las declaraciones preparadas no son lo mismo que las consultas parametrizadas. Las declaraciones preparadas son simplemente declaraciones que se pasan a un módulo que realiza la limpieza por usted.
Eso no quiere decir que la desinfección no sea útil, simplemente no es útil para prevenir SQLi. Sin embargo, aún debe hacerlo para evitar las secuencias de comandos entre sitios almacenadas. Elimine todo lo que un navegador pueda reconocer como HTML o JS o CSS si está almacenando cualquier entrada no confiable que pueda mostrarse en una página.
TL; DR Parametrice sus consultas para proteger de SQLi; prepáralos para protegerlos de XSS almacenados.
EDITAR: Me acabo de dar cuenta de que su expresión regular no parece tener en cuenta los puntos y comas, por lo que podría lograr una inyección contra ella con bastante facilidad.
Esto no escapa a todos los caracteres necesarios para la inserción segura de una cadena en la base de datos.
Puedes escapar $ data con mysqli_real_escape_string para evitar que falle durante la eliminación de caracteres. insertar.
Aquí está la lista de caracteres .
Lea otras preguntas en las etiquetas sql-injection php