¿Qué es security.txt?
El fichero security.txt es un estándar que permite a las organizaciones mostrar información concreta sobre cómo reportar vulnerabilidades de seguridad, incluyendo contactos o políticas de divulgación.
Mientras que ficheros similares como robots.txt controlan la interacción con rastreadores web, security.txt está destinado a ser leído por humanos y fomentar la colaboración en ciberseguridad.
Las dos ubicaciones más comunes para emplazarlo es en /.well-known/security.txt o alternativamente, en la raíz del sitio web, según el estándar RFC 91161.
¿Cuál es el formato y estructura de security.txt?
Hay dos campos obligatorios:
| Campo obligatorio | Descripción |
|---|---|
| Contact | Cómo contactar al equipo de seguridad. Puede estar indicado en más de una ocasión y admite un teléfono, email o URL. |
| Expires | Fecha y hora de expiración en el que security.txt ya no será válido. Debe estar en formato ISO 86012. |
Con esto es suficiente para la mayoría de casos. ¿Simple, verdad? Con especificar una dirección de email y la fecha de expiración.
Fíjate en este ejemplo de un fichero security.txt básico:
Contact: mailto:[email protected]
Expires: 2028-12-31T23:59:59.000ZAhora bien, si quieres completarlo con más datos, existen otros campos opcionales:
| Campo opcional | Descripción |
|---|---|
| Preferred-Languages | Idiomas admitidos para los reportes. Admite múltiples y es ideal ponerlo por orden de preferencia. Debe estar formato ISO 636-1. |
| Acknowledgments | En su caso, enlace donde se otorgue reconocimiento a investigadores que reportaron vulnerabilidades en el pasado. |
| Canonical | La URL principal donde se ubica el archivo. Muy recomendado, especialmente si hay varios subdominios o ubicaciones. |
| Policy | URL donde se detallen las reglas y procedimientos sobre cómo reportar vulnerabilidades. |
| Encryption | Enlace de la clave pública PGP, en el caso de que queramos ofrecer comunicaciones seguras. |
| Hiring | URL para ofertas de empleo relacionadas con la ciberseguridad. |
En función de la página web que revisemos, encontraremos ficheros más elaborados como sería el caso de Google.
Al ser una organización mucho más grande, incluyen enlaces específicos para reglas e información sobre cómo hay que reportar, así como posibles recompensas.
Google no es la única empresa que lo utiliza. Las tecnológicas importantes como AWS también lo tienen, y muy curiosamente a nivel local también he visto algunas organizaciones públicas como la Real Academia Española o el Ayuntamiento de Madrid utilizándolo.
Para encontrar más ejemplos se puede utilizar un «Google Dork»: inurl:security.txt filetype:txt. Opcionalmente puedes añadir site:es al final para acotar tu búsqueda a páginas de España o de la extensión de dominio que prefieras.
Beneficios de implementar security.txt
El único beneficio claro que veo es que se crea un canal de comunicación estandarizado con los investigadores de seguridad, además de permitir indicar pautas para el reporte de vulnerabilidades. Esto puede ayudar a redirigir parte de los reportes y comunicaciones no deseados en esta materia hacia un canal específico de la web.
Y, en algunos casos, podría incluso disminuir la probabilidad de que las vulnerabilidades se divulguen públicamente.
Limitaciones y consideraciones
Pese a que la utilización de inurl:security.txt puede ser una magnífica práctica para organizaciones grandes, no le veo ninguna utilidad para webs pequeñas ya que hay que tener algunas consideraciones al respecto.
Falta de adopción
Su uso no es obligatorio y por ello, no todos los sitios implementan. Las empresas que tienen equipos grandes y son proactivas en ciberseguridad, suelen añadirlo.
No garantiza la seguridad por sí solo
security.txt únicamente define un canal de comunicación, pero no previene ataques ni vulnerabilidades, ni asegura que las organizaciones vayan a actuar rápidamente.
Riesgo de spam
Al exponer un punto de contacto público, se incrementa el riesgo de recibir reportes falsos o de impacto nulo o bajo, spam e intentos de phishing.
Mi experiencia, qué
Desde 2022, he incluido el archivo security.txt en todas las webs en las que he trabajado.
Para este ejemplo, he seleccionado tres de ellas y he clasificado en diferentes categorías los mensajes recibidos. Se tratan de webs de tráfico medio-bajo que suman entre todas 350.000 visitas mensuales.
| Categoría | Mensajes recibidos | Porcentaje |
|---|---|---|
| Reportes genéricos, sin impacto real | 2 | 25% |
| Reportes incorrectos | 1 | 12,5% |
| Búsqueda de trabajo | 3 | 37,5% |
| Solicitud de más información sobre el programa | 1 | 12,5% |
| Herramientas automatizadas | 12,5% |
Uno de los mensajes que recibimos, indicaba lo siguiente:
During our web-wide review, we observed an issue with the security.txt file on your domain, potentially affecting your site's security posture.
El supuesto problema era Ensure every line, including the last one, ends with a line feed character (RFC9116 Section 2.2).
Referencias
[1] Foudil, E., & Shafranovich, Y. (2021). A File Format to Aid in Security Vulnerability Disclosure. https://datatracker.ietf.org/doc/rfc9116/
[2] International Organization for Standardization. (2019). ISO 8601-1:2019 - Date and time - Representations for information interchange - Part 1: Basic rules. https://www.iso.org/standard/40874.html