Era el año 2011 cuando yo pedía que las webs tuvieran un fichero Hackers.TXT para que los investigadores supieran cómo y de qué manera tenían que reportar las vulnerabilidades de las webs de las empresas sin meterse en ningún lío, y hacerlo además de forma responsable. Que pudieran saber si hay un Bug Bounty, si hay canales especiales, si hay que utilizar determinadas claves de cifrado, etcétera.
Figura 1: RFC 9116: Llegó el estándar de Security.TXT,
la evolución de aquel Hackers.TXT
Aquella petición que yo hice generó un hilo de debate en muchos sitios, como en Stack Overflow [hackers.txt], donde la gente preguntaba por cuál era la definición de ese fichero, si existía algún formato en concreto, o alguna ubicación en detalle donde buscarlo en una web.
 |
| Figura 2: Petición de definición de hackers.txt |
En 2013 ese movimiento creció, y más gente pidió que se estandarizase, al mismo tiempo que crecía el interés por la profesión de capturar Bug Bounties, es decir, ser un Cazador de Recompensas en busca de bugs que sean pagados.
Pero no fue hasta el año 2017 que apareció la idea de Security.TXT como una evolución para estandarizar ese fichero para hablar con los Security Researchers directamente desde la web. Para ello se creó en el IETF un grupo de trabajo para ver cómo dar formato a esta idea.
 |
| Figura 4: Draft para Security.TXT |
El resultado de ese trabajo ha sido el RFC9116, que como bien indica es un Formato de fichero para ayudar en la revelación de vulnerabilidades, que a partir de ahora podrá ser utilizado por todos los equipos de seguridad como parte de su política de seguridad en la web. Que podrá ser leído de forma automática por las herramientas de pentesting, y que ayudará en su trabajo a los Security Researchers.
El formato es bastante sencillo, en modo TXT, y con una forma de localizarlo bastante sencilla. En lugar de estar en la raíz, va a estar situado en .well-known/security.txt, por lo que es ahí donde deberán mirar tus herramientas ahora mismo.
Figura 6: Ubicación oficial de security.txt
Además, se podrá indicar la forma de contactar con los equipos de seguridad, tanto con direcciones de correo, números de teléfono o con webs de información extendida que puedan llevar a otros canales, con protocolos de comunicación, etcétera.
Figura 7: Información de contacto para reportar bugs
Y si hay métodos de comunicación cifrada, para proteger la información que pueda estar enviado el Security Researcher, también se podrán publicar o indicar dónde se encuentran disponibles, en caso de que estén en servidores DNS, por ejemplo.
Figura 8: Ejemplos de comunicación de claves de cifrado
Figura 9: Configuración del Hall of Fame
El formato de fichero quedaría por tanto, más o menos, como este ejemplo que tenéis aquí, donde se han configurado algunos de los parámetros que se pueden incluir de una manera normalizada. No son obligatorio ninguno, así que es simplemente para que si tu empresa tiene una política de cómo relacionarse con Security Researchers, Hackers y Bug Bountiers, la puedas comunicar.
Figura 10: Ejemplo de un fichero de Security.txt "compliance"
Así que, al final, aquella idea loca de Hackers.TXT se ha llevado a un final a término. Han sido muchos años, pero si gracias a este fichero los hackers saben si una web tiene un Bug Bounty, o es "Hacker Friendly" o por el contrario es peligroso jugar con ella, se habrá conseguido arreglar posibles problemas a los Security Researchers, así que, happy++.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
No hay comentarios:
Publicar un comentario