Usuarios malintencionados: inyección de código

[letni]

Hola, estoy mejorando la seguridad de mi página web, ahora mismo estoy tratando de evitar ataques por inyección de código.

Por ejemplo si yo tengo un formulario de login y recibo el usuario y la contraseña en las variables $Usuario y $Contrasenia y luego hago:

Código PHP:

  $Consulta = mysql_query("insert into Clientes (Usuario, Contrasenia) values ('$Usuario', '$Contrasenia1')", $Enlace);  
   

puede que me intenten atacar por inyección de código.

¿La forma de solucionarlo sería así?

Código PHP:

  $Consulta = mysql_query("insert into Clientes (Usuario, Contrasenia) values ('" . mysql_real_escape_string($Usuario) . "', '" . mysql_real_escape_string($Contrasenia) . "')", $Enlace);  
   

[emiliodeg]

si señor, esa es la forma ideal

luego seria interesante agregar tambien htmlentities() para traducir caracteres especiales a la hora de contenidos enviados por usuarios (nombre de usuario, firma, etc)

[okram]

Valida el largo de los datos de entrada, dale un límite máximo. En el nombre de usuario haz un límite en cuanto a los caracteres que se pueden usar. Obviamente la contraseña no puede tener esas restricciones, así que la única seguridad allí será la longitud de la cadena y el uo de mysql_real_escape_string(). Cualquier otra cosa, como htmlentities(), va a complicar la comparación de contraseñas.

:sdios:

[elbetonet]

Hola tampoco te olvides de las funciones addslashes() y trim() de php para poner barras invertidas en los caracters omo comillas dobles y limpiar espacios al principio y final de la cadena recibida.

un saludo.

[okram]

mysql_real_escape_string() reemplaza a addslashes(). Y lo mejora, pues está enfocado no sólo a agregar barras invertidas a las comillas.

[letni]

Voy recopilando, primeramente validaría en el cliente la longitud de los campos de entrada como bien dice okram y después he pensado que lo suyo sería crear una función en el servidor así:

Código PHP:

  function FormatearEntradaDatos(&$Cadena) {
    $Cadena = mysql_real_escape_string($Cadena);
    $Cadena = htmlentities($Cadena);
    // $Cadena = addslashes($Cadena); /* Creo que no es necesario ya que mysql_real_escape_string() reemplaza a addslashes() y lo mejora */
    $Cadena = trim($Cadena);
}  
   

y luego hacer la consulta:

Código PHP:

  $Consulta = mysql_query("insert into Clientes (Usuario, Contrasenia) values ('" . FormatearEntradaDatos($Usuario) . "', '" . FormatearEntradaDatos($Contrasenia) . "')", $Enlace);  
   

¿Qué os parece? ¿Estaría correcto lo que he hecho?

Saludos.

[nicolaspar]

Iniciado por okram

mysql_real_escape_string() reemplaza a addslashes(). Y lo mejora, pues está enfocado no sólo a agregar barras invertidas a las comillas.

Así es okram, siempre tan atento usted!.
Vale aclarar que es un dato que está en el manual, habría que leerlo un poco más gente!


Al thread:
Yo le sacaría trim(), no aplica en lo que es el contexto de dicha función, si queres ponerlo en la función de formateo para la salida.

[letni]

Iniciado por nicolaspar

Yo le sacaría trim(), no aplica en lo que es el contexto de dicha función, si queres ponerlo en la función de formateo para la salida.

¿Entonces quedaría así?

Código PHP:

  function FormatearEntradaDatos(&$Cadena) { 
    $Cadena = mysql_real_escape_string($Cadena); 
    $Cadena = htmlentities($Cadena); 
    // $Cadena = addslashes($Cadena); /* Creo que no es necesario ya que mysql_real_escape_string() reemplaza a addslashes() y lo mejora */ 
    // $Cadena = trim($Cadena); 
}  
   

[argy]

también puedes utilizar strip_tags() para algunos datos(por ejemplo el nombre de usuario), ya que no hay necesidad de poner caracteres especiales como /" o algo asi.

[letni]

Iniciado por argy

también puedes utilizar strip_tags() para algunos datos(por ejemplo el nombre de usuario), ya que no hay necesidad de poner caracteres especiales como /" o algo asi.

Yo voy recogiendo vuestras aportaciones, quedaría así:

Código PHP:

  function FormatearEntradaDatos(&$Cadena) { 
    $Cadena = mysql_real_escape_string($Cadena); 
    $Cadena = htmlentities($Cadena); 
    // $Cadena = addslashes($Cadena); /* Creo que no es necesario ya que mysql_real_escape_string() reemplaza a addslashes() y lo mejora */ 
    // $Cadena = trim($Cadena); 
    $Cadena = strip_tags($Cadena); 
}  
   

[okram]

Con htmlentities los caracteres como < y > son convertidos a sus entidades HTML &lt; y &gt; respectivamente. Por lo tanto, strip_tags() no tendría ninguna utilidad allí.

Además yo usaría strtolower() para proteger aún más la consulta sql .

Código PHP:

  $Cadena = strtolower($Cadena);  
   

Me late que está copiando todas las sugerencias sin siquiera investigar al respecto

[letni]

Iniciado por okram

Me late que está copiando todas las sugerencias sin siquiera investigar al respecto

En realidad estoy probando cada una de ellas en un archivo php a parte que recibe una cadena mediante POST a partir de un formulario html.

[nicolaspar]

Iniciado por okram

Con htmlentities los caracteres como < y > son convertidos a sus entidades HTML &lt; y &gt; respectivamente. Por lo tanto, strip_tags() no tendría ninguna utilidad allí.

Además yo usaría strtolower() para proteger aún más la consulta sql .

Código PHP:

  $Cadena = strtolower($Cadena);  
   

Esto si que es raro...no comprendo donde aporta poner en lower el string, además me estarías rompiendo el formato en por ejemplo comienzos de oraciones



letni, algo básico en este mundo (no en PHP sino en programación) son los datos de entrada/salida.

Tenés que tener bien en claro que son ambos y que peligros tenés en cada caso (acá estamos viendo como tratar los de entrada), entonces, sabiendo esto yo lo que guardaría en la db es el dato en bruto, cuidando que no me rompa nada y equilibrando los procesos (Con esto me refiero a que SI podés por ejemplo limpiar de XSS en la entrada, aunque no tenga nada que ver con "sql inyección" y no en la salida por cada pedido, donde no es algo que necesites tener en la db ya que se supone como maligno.)

El htmlentities, strip_tags, trim, nl2br, y demás están bien, pero cuando necesites de ellos, para guardarlos no es algo que te romperá nada en ese proceso, si en la salida.

Esta regla se puede romper si lo que queres en la db es un dato limpio de tags y demás, pero ahí ya corre tu análisis sobre el sistema que estés realizando.

Espero que esto te despeje un poco del quilombo que tenés en la capocha, y analiza los consejos, ni siquiera los mios son confiables ...si no tenes esta capacidad dedicarte a otra cosa sería una buena opción

Saludos, y cualquier cosa consulta!

[okram]

Iniciado por nicolaspar

Esto si que es raro...no comprendo donde aporta poner en lower el string, además me estarías rompiendo el formato en por ejemplo comienzos de oraciones

Evidentemente (y me alegro que no sea así) estaba queriendo averiguar si letni estaba copiando las sugerencias que le dábamos simplemente porque sí, sin buscar nada al respecto. Te faltó leer las letras "ocultas" antes del

Coincido con nicolaspar. Es mejor dejar en la base de datos los datos tal y como el usuario te los puso, cuidándote de las inyecciones sql. Al pedir cada dato realizas la depuración correspondiente. Es muy similar a los sistemas bbcode, en los que guardas en la bd el mensaje con tags bbcode, y sólo es que procesas estos tags al mostrar un mensaje.

Personalmente solo uso strip_tags() en muy contadas ocasiones. Para meter datos a la bd sólo lo paso por mysql_real_escape_string(), y tengo en la bd un dato "verdadero". Luego al mostrar aplico htmlentities y funciones para XSS, y así tengo un dato "corregido".

letni, te sugiero leas el manual de php para cada una de las funciones que se mencionaron aquí, y así empieces a proteger tu sistema.

[nicolaspar]

Iniciado por okram

Evidentemente (y me alegro que no sea así) estaba queriendo averiguar si letni estaba copiando las sugerencias que le dábamos simplemente porque sí, sin buscar nada al respecto. Te faltó leer las letras "ocultas" antes del

Juro que las vi, hasta en el quote de letni. Ya me estaba asustando...que ingenuo que fui :P

[argy]

Iniciado por okram

Además yo usaría strtolower() para proteger aún más la consulta sql .

Código PHP:

  $Cadena = strtolower($Cadena);  
   

Me late que está copiando todas las sugerencias sin siquiera investigar al respecto

MySql es insensible a mayúsculas y minúsculas no entiendo porque protegería escribiendo select... o SELECT...

[okram]

3 mensajes arriba argy O fíjate bien en la cita que pusiste. No ayuda en nada a la protección SQL, pero si ayuda a ser críticos con las respuestas/sugerencias que nos dan, y a no ser meros "loros" que repetimos sin tener idea de lo que hacemos

[argy]

Iniciado por okram

pero si ayuda a ser críticos con las respuestas/sugerencias que nos dan, y a no ser meros "loros" que repetimos sin tener idea de lo que hacemos

mmm bueno al menos tengo idea de lo que hago.

[nicolaspar]

Iniciado por argy

mmm bueno al menos tengo idea de lo que hago.

Pero lees a medias los threads, o que es peor...no sabes interpretarlos
(Tal como lo hice yo) :P

[letni]

Iniciado por okram

Evidentemente (y me alegro que no sea así) estaba queriendo averiguar si letni estaba copiando las sugerencias que le dábamos simplemente porque sí, sin buscar nada al respecto.

Como dije estaba probando todas en un archivo PHP a parte. Entonces viste que no cai en lo de strtolower(), ¿no? :)

Iniciado por nicolaspar

Espero que esto te despeje un poco del quilombo que tenés en la capocha, y analiza los consejos, ni siquiera los mios son confiables ...si no tenes esta capacidad dedicarte a otra cosa sería una buena opción

Saludos, y cualquier cosa consulta!

Tranquilo que suelo probar las cosas miles de veces, jeje.

Saludos.

[arcanisgk]

pero entonces como deveria quedar el codigo final????? para evitar algun error??'

[letni]

Iniciado por arcanisgk

pero entonces como deveria quedar el codigo final????? para evitar algun error??'

Pues como dice okram lo suyo es validar la cadena con mysql_real_escape_string() para tener el dato verdadero el que mete el usuario pero evitando que nos haga inyección de código y luego al mostrar ese dato se aplica htmlentities() y otras funciones para XSS para así tener el dato con un formato adecuado.

Resumiendo, coge el dato y aplícale la función mysql_real_escape_string() y evitamos la inyección de código de usuarios malintencionados.

Saludos y suerte.

[argy]

Iniciado por nicolaspar

Pero lees a medias los threads, o que es peor...no sabes interpretarlos
(Tal como lo hice yo) :P

al menos no ocultes lo que escribes, que pena
estamos hablando de Inyección Sql, entonces se discute eso, por ejemplo yo dije que con strip_tags se podría filtrar los datos ingresados (básicamente etiquetas html y php), en datos que no tienen porque tenerlo (ejemplo nombre de usuario, apellidos y nombre, etc) pero habrán otros que si es necesario mantenerlos con el formato ingresado, eso era mi aporte, pero sino lo creen que es una aporte no hay problema, por ejemplo aquí mucho se ha hablado de mysql_real_escape_string(), pero básicamente ésta función es de mysql, así que no debe confiarse mucho, porque además si deseo conectarme a otro tipo de base de datos diferente a mysql, entonces tengo que buscar alguna otra función que sea similar a mysql_real_escape_string(), entonces lo que deberíamos de hacer es un código que sea transportable a cualquier entorno sin depender de un SGBD en especial.

[okram]

Tiene sentido discutir por eso?

letni en su primer mensaje dio a entender que usa mysql como motor de base de datos, viendo los códigos que puso. En base a eso es que se dan sugerencias que se adapten a su situación actual, y para mysql, mysql_real_escape_string() es suficiente para evitar una inyección sql, que era de lo que se trataba la pregunta.

Para otros tipos de ataques podrían servir htmlentities(), strip_tags() y funciones definidas por el usuarios, como para evitar XSS, y como aportes están bien, nadie dijo que no.

Un saludo,