LA IMPORTANCIA DE UN FILTRADO CORRECTO

banner-articulo-sino-el-como

Hace ya unas semanas que debía pasar por el blog, aunque fuera para decir ‘Hola’ y presentarme, pero no encontraba el momento ni la forma adecuada y, la semana pasada, mientras trabajábamos una mañana más como otra cualquiera, nuestro compañero y amigo @THeXC3LL me dio una idea estupenda y no podía dejar pasar esa oportunidad para aparecer por aquí.

 

Resulta que, como ya sabéis muchos, hace unos meses inauguramos nuestro repositorio de wordpressa-reposiroty-2plugins y themes vulnerables de WordPress (y si no lo sabéis, ya estáis tardando en conocerlo aquí :P), el sitio es bastante sencillo e intuitivo, al entrar tenemos las vulnerabilidades que se han encontrado durante el mes actual en el menú de la izquierda. Clicando en cualquiera vemos la información del plugin/theme en cuestión y la vulnerabilidad encontrada. Además podemos navegar por los meses para ir viendo todos los que se han ido encontrando así como un buscador por si queréis saber si un plugin concreto es vulnerable (o al menos si nosotros lo hemos encontrado).

Pues bueno, sin más rollos, el caso es que nuestro amigo @THeXC3LL se dedicó a entretenerse un rato con la web, buscando posibles agujeros de seguridad o problemas que no hubiéramos encontrado y, efectivamente, si bien no llegó a sacar información, sí consiguió generar un error.

Esto, es posible que a muchos no os parezca gran cosa, pero podría suponer en cualquier web un ataque Blind SQL, haciendo constantes consultas al servidor con diferentes valores. Estos ataques se basan, simplemente, en sacar un error en la web cada vez que la consulta a la base de datos está mal formulada pero, ¿y si formulamos una consulta a modo de pregunta de verdadero/falso a la base de datos? Podríamos utilizar los resultados en el navegador (respuesta del servidor) como respuesta a la pregunta: si se nos muestra el error, entendemos que la respuesta es FALSO, en caso contrario, el servidor nos dice que es VERDADERO. Aunque estos ataques son más pesados, existen herramientas que lo automatizan (SQLMAP) y siguen siendo un riesgo potencial, pero como yo no estoy aquí para deciros cómo explotarlos, sino cómo defenderos de ellos, vamos al lío.

Resulta que el problema era el siguiente, al entrar a la información de un plugin, para conocer qué plugin se está seleccionando, pasamos por GET el id de dicho plugin en la base de datos, es decir, tomábamos el id de la URL en forma de ‘.php?id=XX’ donde XX es el número del plugin. Lo que hizo él fue ni más ni menos que meter algo que no fuera un número. Esto provocaba que al filtrar un plugin por un campo numérico pasando una cadena que no era un número, la base de datos sacaba un error y, consecuentemente, al procesarlo con php éste sacaba otro error y eso era lo que veía nuestro amigo. ¿Por qué no nos habíamos percatado de esto? Simple, para evitar este tipo de ataques, siempre hay que filtrar las variables que se recogen, evitando caracteres potencialmente peligrosos (es decir, todos los caracteres prescindibles que puedan usarse/significar algo en consultas SQL). ¿Lo hacíamos? Sí, con un filtrado genérico para las variables, evitando una serie de caracteres peligrosos. ¿Por qué ocurría entonces dicho error? Pues de ahí el título del post. Para tener un control seguro de las variables hay que tener un filtrado acorde a los tipos de las variables que filtramos. Sí, lo sé, en php no declaramos variables de un tipo u otro y, de hecho, el filtrado sólo se hace de strings, pero sabemos que tenemos tipos distintos en nuestra base de datos, por lo que hay que asegurarse de que lo que tratamos es eso.

Bueno, todo esto está muy bonito pero ¿soluciones?. Pues hay varias, aunque voy a comentar las 2 que me parecen más directas o fáciles.

  • Por un lado existe filter_var() en PHP. Esta función intrínseca al lenguaje recibe dos parámetros: el primero es la variable a filtrar y el segundo una constante definida por PHP para una extensa variedad de filtros. Puedes consultar aquí(http://php.net/manual/es/filter.filters.php) los filtros disponibles.
  • Por otro lado, el problema del método anterior es que las variables, que a veces están introducidas por los usuarios, tienen que entrar en el formato definido por PHP y carecemos de un control exhaustivo sobre la misma. En Quantika14, a menudo debemos controlar la variable introducida para modificaciones, normalizaciones, etc. por ello trabajamos con filtros propios. Para evitar el problema del repositorio, simplemente hemos tenido que crear filtros específicos: un filtro para números, un filtro para e-mails, un filtro para fechas, etc. además del filtro genérico. Para hacer nuestros filtros, os recomendamos que utilicéis preg_replace, que recibe 3 parámetros: el primero es una expresión regular que define qué caracteres se permiten/se prohíben, el segundo es la string por la que serán sustituidos y el tercero es la variable sobre la que se va a trabajar.

Como conclusión, podríamos decir que hay 3 niveles de desarrollador respecto a la seguridad:

 

  • El básico/newbie/despreocupado/…, que simplemente tira líneas de código, sin prestar atención a la calidad del código, la optimización del mismo, la claridad a la hora de leerlo ni, qué duda cabe, la seguridad del software. Este tipo de desarrollador, respecto al artículo que nos ocupa, directamente mete los datos en la BD, es decir, su software tiene más agujeros que un queso gruyer, a veces hasta pareciera que compiten por ser lo más vulnerables posible.
  • El medio/común/responsable/bonachón, que, aunque no es un gurú del sector, se preocupa por conseguir resultados lo mejor posible en los ámbitos comentados anteriormente, aunque se queda a medias. Igualmente, por pereza/prisas/etc., en muchos casos, desarrolladores con más experiencia se despreocupan. Estos son los que filtran las variables de manera genérica, los que escriben un código bonito aunque no por ello especialmente legible por terceros (problemas con los nombres de variables y funciones) y los que la optimización de códico les queda grande.
  • El experto/experimentado/campeón/killer/yoda que conoce los problemas y se preocupa por ellos, hace filtrados específicos, sigue metodología de nombrado, comenta lo necesario aunque no excesivamente y blinda sus aplicaciones.

Siendo realistas, todos hemos pasado por todos los niveles, nadie nace sabiendo e igualmente, nadie es siempre un killer y todos bajamos alguna vez a ser un bonachón, pero hay que ser conscientes de cómo se hacen las cosas y, cuando hacemos algo público es necesario dar el 110% de nuestros conocimientos. Nuestros enemigos no nos atacan como newbie ni como bonachones y, aunque lo hicieran, siempre habrá algún yoda para el que debemos estar a la altura sino queremos acabar como la estrella de la muerte.

¡Un saludo Quantikos!

Add a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *