Si bien mysql_escape_string() es un método correcto para prevenir la inyección de SQL, las consultas parametrizadas son un enfoque mucho mejor. mysql_escape_string() todavía no es perfecto; por ejemplo, lo siguiente es vulnerable a la inyección de SQL:
$q="select * from user where uid=".mysql_real_escape_string($_GET[uid]);
El PoC es simple:
http://localhost/vuln.php?uid=sleep(30)
¡Usa consultas parametrizadas!
htmlentities() , o htmlspecialchars() evitará algunos tipos de XSS. No evitarán que XSS en eventos DOM . Este método no evitará inyectar eventos, por ejemplo: value='junk' onclick=alert(/xss/) . htmlspecialchars($var,ENT_QUOTES) es un poco mejor, porque evita la inyección de eventos DOM, pero aún puedes secuestrar un evento (consulta la publicación del blog "Es un evento DOM").
Entonces estas dos funciones mitigarán parcialmente dos vulnerabilidades de un par de miles . Para llamar a algunos de los grandes infractores que no serán mitigados por mysql_real_escape_string() o htmlentites() tenemos: Traversal del directorio (y LFI / RFI para PHP), inyección de LDAP, inyección de XPATH, división de respuesta HTTP, inyección de archivo de registro ... . y la lista continúa.
La entrada de escape no tiene nada que ver con la eliminación de "caracteres prohibidos". Se trata de convertir caracteres de escape (o secuencias de caracteres) en su " character literal " de modo que los datos controlados por el atacante todavía se interpretan como datos, y no como código ejecutable.