En la conferencia de seguridad recien pasada, tuve la oportunidad de presentar el Proyecto Secureless, demostrando la realidad de las vulnerabilidades web de distintos sitios, por categoria, dominio y por tipo de organizacion.
Durante aproximadamente 7 meses hemos estado recopilando sitios webs con distintas vulnerabilidades, gracias a nuestras propias investigaciones o colaboraciones de distintos usuarios, hasta la fecha registramos aproximadamente 1058 sitios web, de distintos paises, distintos tipos de entidades (universidades, bancas, etc) y con distintos estados. Actualmente en Secureless manejamos 3 tipos de estados, las Reportadas, No Reportadas
La diferencia que existe entre las Reportadas y las Sin Reportar, principalmente se da porque los sitios web no publican un correo o alguna forma de contacto para poder reportar este tipo de fallas, por lo general se limitan a poner un formulario de “consultas” y muchas veces en bancos, universidades o sitios del gobierno, hay que completar un formulario con cientos de campos obligatorios.
Los sitios web que realmente deberian tener este tipo de procedimiento como los bancos, Universidades o sitios del gobierno que manejen información sensible de personas, no lo hacen. Muchas veces debemos enviar el reporte a correos genericos y/o aleatorios como contacto@dominio, info@dominio o webmaster@dominio, sin tener respuesta.
La relación que existe entre las Reportadas y las Solucionadas, nos demuestra que de alguna forma estamos apuntando para el lado correcto, ya que el 90% de las vulnerabilidades reportadas se solucionan.
De los tipos de vulnerabilidades, hay dos categorías que pelean el puesto para ser los que más sitios registran, el SQL Injection y al Cross-Site Scripting
Es curioso, ya que una es client-side (xss) y la otra server-side (sql-i), pero ambas ocurren por una mala sanitización de los parametros de entrada.
La que los sigue es Full Path Disclosure, una vulnerabilidad que por si sola no es muy critica y que muchas veces se le da la responsabilidad al encargado del servidor, que no deshabilita los errores o el debug, aunque segun yo, el programador debería ser capaz de manejar los errores y validar los parametros de entrada para evitar el crash de la aplicación y asi evitar cualquier tipo de error sin atajar. El tipico ejemplo, cuando modificamos los parametros por GET y transformamos una variable en un Array.
Si analizamos la cantidad de sitios por tipo de organización, nos encontramos con el siguiente gráfico:
Las universidades son de las entidades (segun nuestro criterio) que más vulnerabilidades tienen, ya que muchas de ellas les abren espacios a sus clientes alumnos, por lo general un servidor compartido entre usuarios y en algunos casos extremos, un servidor compartido con aplicaciones de la universidad (intranets, etc).
Luego viene los del gobierno, que mientras más sitios y sistemas ofrecen, menos control tienen sobre las aplicaciones y sobre los datos que manejan. Es muy comun en sistemas y sitios del gobierno encontrar tecnologias antiguas y en muchos casos, obsoletas.
Con eCommerce, me refiero a sitios que ofrecen “comercio por internet”, como PC Factory, Falabella, Ripley, etc.
Finalmente tenemos a los queridos Bancos, que sinceramente ellos ni si quiera deberian aparecer en este listado.
El último gráfico, corresponde a sitios segun su pais o dominio
No significa que Chile sea mas vulnerable que los otros, simplemente que en un principio nos dedicamos unicamente a almacenar sitios chilenos, pero poco a poco fuimos aceptando colaboraciones de otros paises y otros dominios.
noviembre 30, 2011 a las 9:40 am
Pensaron en hacer que secureless sea un intermediario para reportar?
Por ejemplo, que al mandar el email a ustedes haya una opcion para que contacten a security@example.com, webmaster@example.com, etc
Tambien podrian comunicarse con otros certs. Por ejemplo, si es un .gov.ar pueden contactar a arcert
A veces yo mando vulnerabilidades a secureless y no las reporto para no tener que buscar la forma de contacto, escribir un email y aguantarme a un admin que se lo toma mal, si ustedes hacen de intermediarios seria mucho mas facil
noviembre 30, 2011 a las 10:16 am
Hola seth:
A nosotros nos pasa lo mismo, intentamos reportar las que nos llegan pero no sabemos a quien …
si la persona que reporta, sabe a quien podriamos contactar par aavisarles, seria bueno que nos lo dijeran.. Vamos a evaluar la opcion de ponerun “email de contacto” para contactar al responsable
gracias por el feedback!
diciembre 1, 2011 a las 3:17 am
Podrian mandar email a las direcciones comunes que muchas veces existen, es mejor que nada
Lo de permitir poner un email tambien está bueno
diciembre 30, 2016 a las 6:05 am
I have seen this on TV before, what a great idea. my son has a rasor scooter and gets his dog to pull him along that way.Dennis’s last blog post..
febrero 18, 2017 a las 5:23 pm
SIGH!!!! Well Laker Haters…..As the old man of TSS … I just have to say this….. SHUT THE FUCK UP WHEN GROWN FOLKS ARE TALKIN!!!!!!!!!! That is all ….=========================================================================Stay Classy Laker fans…Stay Classyeffin turk and his voodoo pins lol