Información Importante Sobre el Contenido
Estas accediendo al contenido antiguo del blog. Este artículo "Secureless: Estadisticas de sitios web vulnerables" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.
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.
Información Importante Sobre el Contenido
Estas accediendo al contenido antiguo del blog. Este artículo "Secureless: Estadisticas de sitios web vulnerables" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.
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