mysql_real_escape_string y html_special_chars lo suficiente?

Esta pregunta se hace mucho, pero todavía no he encontrado una respuesta directa en stackoverflow. ¿Son estas dos funciones suficientes o no? Hay muchos comentarios contradictorios en Internet “sí, está bien”, no, nunca lo use “. Otros dicen que usan PDO, lo cual no entiendo. Solo soy un principiante de PHP, así que no lo hago. Entiendo completamente todos los detalles de la seguridad. He intentado leer y comprender lo siguiente, pero muchos no tienen mucho sentido para mí.

http://ha.ckers.org/xss.html
¿Htmlspecialchars y mysql_real_escape_string mantienen mi código PHP a salvo de la inyección?

¿Qué pasa si uso preg_replace para quitar los caracteres no deseados?

Estoy increíblemente confundido y no sé por dónde empezar.

EDITAR: ¿Podría alguien recomendar también cómo hago para entender las declaraciones preparadas (suponiendo que esta sea la mejor opción).

Sam, si estás almacenando la entrada en una base de datos, para evitar la inyección de SQL y XSS, esas dos funciones son suficientes. Si está almacenando contraseñas, debe encriptar las contraseñas con cifrado unidireccional (es decir, no se pueden descifrar).

Permítanme ampliar mi respuesta: en primer lugar, la inyección SQL es un método en el que un usuario malintencionado intentará modificar su statement SQL para que cumpla su voluntad. Por ejemplo, digamos que tiene un formulario de inicio de sesión. Al insertar uno de los siguientes valores en un formulario no protegido, podré iniciar sesión en la primera cuenta sin conocer el nombre de usuario o la contraseña:

 ' or 1=1 -- 

Hay muchas versiones de la inyección anterior. Examinemos lo que hace con el SQL ejecutado en la base de datos:

El PHP: mysql_query (“SELECT * FROM usuarios WHERE username = ‘”. $ Username. “‘ AND password = ‘”. $ Password. “‘;”);

Cuando se ejecuta lo anterior, se envía el siguiente SQL a la base de datos:

 SELECT * FROM users WHERE username='' or 1=1-- ' AND password='' or 1=1--'; 

La parte efectiva de este SQL es esta: SELECCIONE * FROM usuarios WHERE username = ” o 1 = 1

como el doble guión (con el espacio después) es un comentario, eliminando el rest del enunciado.

Ahora eso le da acceso al usuario malicioso. Con el uso de una función de escape como mysql_real_escape_string, puede escapar del contenido para que lo siguiente se envíe a la base de datos:

 SELECT * FROM users WHERE username='\' or 1=1-- ' AND password='\' or 1=1--'; 

Eso ahora se escapa de las comillas, haciendo las cadenas previstas, solo eso – cuerdas.

Ahora veamos algunos XSS. Otro usuario malintencionado desea cambiar el diseño de una página. Un ataque XSS bien conocido fue el ataque de Facespace en Facebook en 2005. Esto implica insertar HTML sin procesar en formularios. La base de datos guardará el HTML sin procesar y luego se mostrará a los usuarios. Un usuario malintencionado podría insertar algo de javascript con el uso de la etiqueta de script, que podría hacer cualquier cosa que javascript pueda hacer.

Esto se escapa convirtiendo a & ltl; y> respectivamente. Utiliza la función html_special_chars para esto.

Esto debería ser suficiente para asegurar el contenido normal en un sitio. Sin embargo, las contraseñas son una historia diferente.

Para las contraseñas, también debe encriptar la contraseña. Es aconsejable usar la función crypt de PHP para esto.

Sin embargo, una vez que la contraseña está encriptada y guardada en la base de datos como una contraseña cifrada, ¿cómo puede descifrarla para verificar que sea correcta? Respuesta fácil: no la descifrarás. SUGERENCIA: una contraseña siempre se cifra con el mismo valor.

¿Pensaba ‘podemos cifrar la contraseña cuando el usuario inicia sesión y la compara con la de la base de datos’, está en lo cierto …

Depende de para qué estás usando la entrada y hacia dónde va.

lo único que se debe asumir cuando se desinfecta la información para las aplicaciones de php es que hay muchas personas inteligentes por ahí, y si realmente quieren romper su aplicación, encontrarán la manera de hacerlo.

seguir las guías que enumeró y otras guías son un gran comienzo. pero luego cada desinfección que haga incurrirá en una cantidad no trivial de tiempo y memoria para realizar.

así que todo depende de para qué estás usando la entrada y hacia dónde va.

mysql_real_escape_string y html_special_chars son buenas utilidades, pero no debes depender únicamente de ellas y tampoco son siempre necesarias.

no se desanime, ya que incluso los sitios maduros y bien progtwigdos tienen que mantenerse al día con lo último en xss y otros ataques. divertido juego de gato y ratón.

un lugar donde puedes comenzar es con un framework, me gusta codeignitor. revisa sus clases de seguridad para ver cómo lo manejan.

o mejor aún, escriba un procesador de formularios simple e intente encontrar formas de ejecutar código arbitrario usted mismo. te sorprendería la cantidad de formas en que puedes pensar.

Suponiendo que está preguntando por la seguridad, hay un problema con mysql_real_escape_string.

Esta función no tiene absolutamente nada que ver con la seguridad.

Siempre que necesite escaparse, lo necesita a pesar de la “seguridad”, pero solo porque es requerido por la syntax de SQL. Y donde no lo necesites, escapar no te ayudará ni un poco.

El uso de esta función es simple: cuando tiene que usar una cadena entre comillas en la consulta, debe escapar de su contenido. No debido a algunos “usuarios malintencionados” imaginarios, sino simplemente para escapar de estas comillas que se utilizaron para delimitar una cadena. Esta es una regla extremadamente simple, pero extremadamente confundida por gente de PHP.

Esta es solo una función relacionada con la syntax, no relacionada con la seguridad.

Dependiendo de esta función en cuestiones de seguridad, creer que “protegerá su base de datos contra usuarios maliciosos” lo llevará a la inyección.

Una conclusión que puedes hacerte tú mismo:
No, esta función no es suficiente .

Las declaraciones preparadas tampoco son una bala de plata. Le cubre la espalda solo en la mitad de los casos posibles.