Seguridad, Cross Site Scripting, SQLInjection. Funciones para ello. Me ayudáis?

[darkgaze]

Después de leerme infinitos manuales y fórmulas ahora tengo tantas funciones que he ido descartando.

Si me podéis aclarar cuándo usar cada una OS ESTARÍA muy agradecida.


He sacado en claro lo siguiente para controlar datos pasados por POST en formularios:

Código PHP:

   
//para limpiar campos de texto donde se pueden poner enter... (o no???)
 
$variable_limpia = nl2br(htmlentities($variable_sucia, ENT_QUOTES,'UTF-8'));
 
//para campos de texto simples de una linea
 
$variable_limpia = htmlentities($sucia, ENT_QUOTES,'UTF-8'); 
   

Ayer leí que hay también una función:

mysql_real_escape_string()


pero maldita sea... ¿y ahora esto que hago con ello?. Tenéis idea de cuándo usar todo?

Me da la sensación que usar nl2br es recomendable en cualquier caso, por si acaso.



Gracias. Si conocéis algún lugar donde encontrar manuales sencillos y directos sobre qué usar (estoy harta de leer cosas... por todas partes).


Gracias, gente

[AlvaroG]

mysql_real_escape_string()

te va a eliminar cualquier caracter "peligroso" para la consulta. Usándolo te evitás problemas de inyección SQL, ya que aunque intenten engañar a tu programa pasándole una cadena "maligna", esta función escapará ciertos caracteres (en particular comillas) y eliminará este riesgo.
Es una "mejora" de addslashes(), se supone que usar una función específica del motor de base de datos es más eficiente.

nl2br solo te puede ayudar en casos de, por ejemplo, inyección de cabeceras de correo electrónico, no te salvará de un ataque de inyección SQL, ya que el salto de línea no tiene un significado para el servidor SQL y por tanto difícilmente alguien lo use en su ataque. Aunque sí en caso de que sea usado, filtrar con nl2br provocará un error en la consulta.

htmlentities no está pensada para la seguridad, y no será más efectiva que mysql_real_escape_string

Por último, si estás recibiendo datos para enviar por correo, deberías directamente eliminar los caracteres de salto de línea (\n y \r) de los campos que no deberían tenerlos, ya que la conversión a <br> no necesariamente te va a salvar de la inyección de cabeceras.


Sobre Cross-site scripting no puedo hablar mucho, nunca investigué lo suficiente.


Saludos.

[darkgaze]

Pero si Htmlentities hace lo mismo que myql_real_escape_tring!

a eso me refiero!. Htmlentities lo recomiendan para usar con la seguridad, en todos los libros que he leido...

lo que no entiendo es por qué usan diferentes en sitios varios. No sé para qué elementos usar cada uno...


htmlentities con las opciones ENT_QUOTES transforma comillas dobles y normales. QUé diferencia hay, pues?

[AlvaroG]

La combinación nl2br+htmlentities se recomienda no por seguridad sino para limpiar datos (y no guardar HTML en la base de datos, o para facilitar la muestra de esos datos luego)

La función de htmlentities es convertir caracteres no ascii a entidades HTML.
Por ejemplo, convierte "á" en "&aacute".

Como debe buscar más caracteres y hacer más sustituciones, es más lenta que mysql_real_escape_string. Esta última va a sustituir solamente los caracteres que necesite sustituir.

Una de las cosas que tenés que comprobar en campos de texto de una sola línea, es que no te introduzcan caracteres de salto de línea (por lo que mencionaba antes de las inyecciones de cabeceras cuando el formulario es usado como fuente de datos para correo electrónico). htmlentities no te va a servir de nada en ese caso, manualmente tenés que eliminar los caracteres \r y \n.

Como casi todo en programación, hay varias maneras de hacer lo mismo. Yo simplemente te comento que htmlentities no es la opción ideal y que su función no es la seguridad. Eso no quiere decir que no funcione


Saludos.