Hay muchos periódicos peruanos que han cambiado su diseño para estar más a la onda Web 2.0, inicio el Comercio, luego peru21, y ahora último Correo (calientito).
Para estar a la altura de la Web 2.0, no sólo basta con agregar RSS a la una Web. Hay otros temas importantes como son estar protegidos contra ataques, en la actualidad cualquier usuario principiante de internet puede buscar y encontrar información de como atacar sitios Webs. El más conocido y ampliamente difundido es el SQL Injection, usaremos a correo para explicarlo mejor (ya que no ha mejorado su seguridad, y sigue dejando puertas libres como en su versión anterior):
Correo tiene un sistema de búsqueda de noticias, y para eso nos da una pequeña cajita de búsquedas:
Cualquier parte de la página de Web, que permita el ingreso de data por parte del usuario puede ser un punto de ataque, en la web todo debe estar bajo el principio: "Todo el ingreso es dañino, hasta que se compruebe lo contrario", es decir que no vale esperar a recibir un ataque para tomar medidas de seguridad.
Lo primero que puede hacer un atacante es verificar si están validando el input del usuario:
Y aquí que puede empezar todo, ya sabemos que no están validando la cadena de búsqueda y que permite que el usuario pueda modificar de alguna manera la consulta para enviar código malicioso a la base de datos.
Hasta aquí ya vemos dos principales principios que no se cumplen:
- Validación del input del usuario
- No mostrar al usuario más información de la necesario
Lo correcto sería validar el input, y además tomar la cadena como tal, sólo como cadena, la no validación del input a su vez lleva a dos posibles acciones del usuario:
- Ejecutar código malicioso contra la base datos.
- Obtener información "sensible".
¿Qué es información sensible?. Por ejemplo en la búsqueda de arriba puedo determinar varios datos importantes: La base de datos que esta usando CorreoPerú, es una base de datos MySql, por la url sabemos que es Php, y con netcraft sabemos que esta usando Apache sobre Linux, el famoso LAMP. Pero además de decirnos que esta usando una base de datos MySql, ya nos dio dos nombres de posibles columnas: nota_titular, y nota_llamada.
Y jugando podemos llegar a otra información sensible:
Bueno acá ya me dio el nombre de la base de datos, y de una posible tabla. Nuevamente, no mostrar al usuario más información de la que necesita.
Y ni se tomaron la paciencia de hacerlo de difícil, desde el cuadro fecha también se puede mandar Sql Injection, desde hace tiempo que existen las expresiones regulares (para validar del lado del cliente y del lado del servidor):
Nueva me esta dando más información de lo que necesita saber el usuario. Lamentable no soy un experto en hacer este tipo de ataques, si no hubiera sacado información :D, justamente el no usar mensajes de error personalizados es aprovechado por los atacantes para obtener toda la información que necesiten antes de hacer un ataque.
¿Cuál es el daño común? Si te permiten enviar consultas con SQL Injection (y no validan), pueden reemplazar todos los links de las noticias y hacerlos que apunten a otro servidor (ataque XSS), y que podría hacer el ataque? pues podría poner publicidad en el sitio Web, o hasta introducir troyanos en la computadora del usuario. Imaginemos que hubieran podido actualizar todos los links de los títulos noticias, lo que pasaría es al ingresar a la portada del diario, todos los títulos linkeables de la noticia tendrán el código malicioso, y dependiendo de varios factores este puede afectar a nuestra computadora o no.
El otro daño común, y menos perjudicial para el usuario final, es el de los llamados hackers, que pueden hacer que una determina noticia o todas las noticias, contenga la Url de su blog...
Me parece que en la versión anterior pude jugar un poco más con el SQL Injection, y llegue a ejecutar algunos querys, pero ya no le dedique tiempo a buscar el nombre de la tabla o columnas, para hacer el famoso update masivo...
Y nada, imagino que después de esta nota, ya no veremos mensajes del tipo: "No te voy a decir que mi base de datos se llama: db_XXX, ni tampoco que mi tabla se llama XXX, mucho menos que si quieres insertar código maliciosos mis columnas son: titular, fecha, etc"
Por cierto, si quieren aprender de seguridad y ataques, visiten el blog del gran Alex.
Saludos,
Subscribe