Reglas de Compromiso en Bug Bounty: Alcance, Safe Harbour y Divulgación

#Qué es un programa de bug bounty

Un programa de bug bounty es una invitación permanente de una organización para que investigadores prueben sus sistemas públicos y reporten fallas de seguridad, normalmente a cambio de una recompensa. La invitación tiene condiciones. Esas condiciones, que suelen llamarse política, indican qué sistemas puedes probar, cómo puedes probarlos, qué no debes tocar, cómo debes reportar y qué promete la organización a cambio.

La política es el reglamento. Los problemas suelen empezar cuando el investigador la saltó o la tomó como un trámite. Un laboratorio enseña a encontrar una falla. La política de un programa enseña dónde tienes permiso para mirar y cuándo detenerte en el límite de esa autorización. Este artículo trata de esa segunda habilidad.

Aquí no vas a probar nada. Vas a leer una política de ejemplo, anotarla y escribir una lista de verificación previa a la prueba que luego podrás reutilizar en programas reales. Los únicos comandos que ejecutas modifican archivos de tu propia computadora.

#Por qué las reglas van antes de la prueba

El riesgo legal es la primera razón que la gente suele dar, y es real. Las leyes de uso indebido de computadoras en muchos países están redactadas de forma tan amplia que un acceso sin permiso puede perseguirse aunque la intención haya sido buena. La Computer Fraud and Abuse Act (CFAA) de Estados Unidos es el ejemplo más conocido. En mayo de 2022, el Departamento de Justicia de ese país cambió la manera en que sus fiscales acusan la investigación de seguridad hecha de buena fe bajo esa ley. La política revisada indica a los fiscales que no acusen a la investigación realizada únicamente para probar, examinar o corregir una falla, que evite causar daño y cuya información se use principalmente para mejorar la seguridad. No cambia la ley. No protege la investigación orientada a la extorsión, Es una política de acusación, no un derecho, y no obliga a fiscales estatales ni a particulares que demanden. Lee el anuncio del DOJ para ver la redacción exacta. No lo tomes como permiso para probar lo que quieras.

La segunda razón es práctica. Un tester que entra a un sistema de pagos, al dominio de una empresa adquirida o a la API de un socio ha tocado algo que el dueño nunca ofreció. Incluso cuando la falla es real, el dueño ahora debe decidir si el reporte es un regalo o un incidente. Quedarse dentro del alcance escrito mantiene la conversación centrada en el bug.

Por eso la regla es simple: si la política no lista un activo como incluido en el alcance, no estás autorizado a probarlo. El silencio no es consentimiento. La respuesta de un agente de soporte solo cuenta cuando la política dice quién puede conceder excepciones, y aun así solo por escrito.

#Cómo leer la política de un programa, paso a paso

Recorre la política siempre en el mismo orden. Cada sección de abajo es una pregunta que debes poder responder antes de que la primera solicitud salga de tu equipo.

#1. Activos dentro y fuera del alcance

El alcance es la lista de activos que el dueño te permite probar. Un activo puede ser un dominio, un rango de IP, una aplicación móvil, una API, un producto o un tipo de cuenta. Una buena política nombra cada activo con exactitud y dice si un comodín como *.example.test cubre todos los subdominios.

Lee la lista de exclusiones con el mismo cuidado. Suele nombrar servicios de terceros que la empresa no posee, como páginas de pago alojadas, proveedores de correo y redes de distribución de contenido. Una política puede dar permiso para probar los sistemas del dueño. No puede dar permiso para probar los sistemas de un proveedor, y cada proveedor tiene sus propias condiciones.

Dos hábitos ayudan. Primero, comprueba a dónde apunta cada nombre incluido en el alcance. Si un nombre resuelve a un host de una plataforma de terceros, lee las condiciones de esa plataforma antes de probar. Segundo, anota la fecha de la comprobación, porque las listas de alcance cambian.

#2. Técnicas permitidas y prohibidas

Las políticas describen las técnicas como permitidas, prohibidas o silenciosas. Trata el silencio como prohibición. Entre los elementos prohibidos comunes están la denegación de servicio, la ingeniería social contra el personal, el acceso físico y los ataques que copiarían o alterarían datos de otras personas. Algunos programas prohíben los escáneres automatizados. Otros los permiten con límites.

Escribe la lista con tus propias palabras antes de empezar: "Permitido: prueba manual de la aplicación web con una cuenta de prueba. Prohibido: denegación de servicio, phishing al personal, escáneres." Si no puedes escribirla, no estás listo para probar.

#3. Límites de tasa y carga

Los límites de tasa protegen los sistemas del dueño y a los demás usuarios. Una política puede fijar un tope de solicitudes, un límite de conexiones simultáneas o una regla como "no más de una prueba por segundo". Si no dice nada, mantén el tráfico bajo y manual. Una ejecución automatizada que te parece inofensiva puede ralentizar un servicio pequeño, y entonces la caída se convierte en tu incidente.

Pon el número en tu lista de verificación. Configura tu herramienta para respetarlo y revisa esa configuración antes de empezar.

#4. Cuentas de prueba

Muchos programas piden que registres una cuenta de prueba, a veces con un patrón de correo específico, y que uses solo cuentas que tú creaste. Algunos prohíben crear cuentas para otras personas, usar el inicio de sesión de un cliente real o probar con datos que no creaste tú. Las pruebas de control de acceso suelen necesitar dos cuentas, así que la política debe decir qué cuentas puedes usar y qué datos puedes crear dentro de ellas.

#5. Manejo de datos

Esta sección decide qué puedes hacer con lo que encuentres. Las reglas típicas dicen que debes detenerte al llegar a datos personales, no descargar más de lo necesario para demostrar el problema, no conservar copias y borrar el material cuando se cierre el reporte. Algunas políticas exigen ocultar datos en las capturas de pantalla.

La regla de detenerse ante datos personales atrapa a mucha gente. Si una referencia directa insegura a objetos (IDOR) te entrega el registro de otra persona, la prueba adecuada suele ser el identificador y una descripción breve, no el volcado de la tabla. Registra lo que viste y deja el resto donde estaba.

#6. Lenguaje de safe harbour

Safe harbour es la promesa del dueño de no iniciar acciones legales contra investigadores que actúen de buena fe dentro de la política. El proyecto disclose.io publica texto de safe harbour y herramientas para organizaciones que quieren redactar el suyo. Su sitio describe el propósito como permitir que las personas reporten problemas de seguridad sin temor a consecuencias legales, y aclara que el material no es asesoría legal.

Lee el texto de safe harbour con atención. Un buen texto nombra sus condiciones, como seguir la política, reportar con prontitud y no usar el acceso para otra cosa. También se limita a los sistemas del programa. La promesa de una empresa no cubre a terceros ni conductas no relacionadas. Si una política no tiene ningún safe harbour, pesa ese hecho antes de probar.

#7. Contacto y términos de divulgación

La sección de contacto indica adónde enviar el reporte y cómo responderá el dueño. Busca un contacto de seguridad, un buzón de la plataforma o un archivo security.txt en /.well-known/. Busca un plazo de acuse de recibo y lo que pasa con el hallazgo después de la corrección.

Los términos de divulgación indican cuándo puedes publicar. Algunas políticas permiten publicar cuando sale la corrección. Otras fijan una ventana contada desde el primer reporte. La página de divulgación coordinada de vulnerabilidades de CISA dice que, cuando un proveedor no responde o no se compromete con un plazo razonable, CISA puede divulgar ya a los 45 días del primer intento de contactar al proveedor. Esa es la regla de CISA para su propio papel, no un número universal. La política de tu programa fija tus términos, y no publicas antes de que lo permitan.

#Divulgación coordinada de vulnerabilidades

La divulgación coordinada de vulnerabilidades (CVD, por sus siglas en inglés) es el proceso en el que quien encuentra una falla la reporta a quien puede corregirla, el proveedor y las demás partes afectadas preparan la corrección y la orientación, y la información se publica cuando las personas que la necesitan pueden actuar. CISA dice que su programa facilita la difusión oportuna y sincronizada de información sobre vulnerabilidades y de las mitigaciones disponibles.

La ISO/IEC 29147, titulada "Vulnerability disclosure" dentro de la serie Information technology, Security techniques, es la norma internacional para el lado externo de ese proceso. Describe cómo un proveedor recibe reportes, se comunica con quien reporta, coordina con otros proveedores y publica avisos. Su compañera, la ISO/IEC 30111, trata de cómo el proveedor maneja la vulnerabilidad internamente. El catálogo de ISO registra el documento como la segunda edición de 2018. Verifica el estado actual en iso.org antes de citarla.

Para quien investiga, el significado práctico es este: un reporte inicia una conversación dentro de un proceso. Reportas, esperas el acuse de recibo, compartes lo necesario para reproducir el problema y respetas el plazo acordado. Esos pasos siguen el modelo de la norma, incluso cuando el programa nunca la menciona.

#Por qué probar fuera del alcance no está autorizado

La autorización es un permiso que concede el dueño de un sistema, y tiene un límite. El alcance es ese límite escrito. Todo lo que queda fuera es un sistema ajeno para los fines de tu prueba, y acceder sin permiso puede constituir acceso no autorizado según muchas leyes de uso indebido de computadoras.

Tres cosas salen mal cuando alguien prueba fuera del alcance. Primero, puede equivocarse sobre quién es dueño del activo, y la prueba cae sobre un tercero inocente. Segundo, el dueño puede haber excluido el activo por un motivo que tú no ves, como un sistema heredado frágil. Tercero, aunque tengas razón, el reporte se vuelve más difícil de aceptar, porque ahora el dueño debe decidir si premia un hallazgo que nunca pidió buscar.

La respuesta honesta a una duda sobre el alcance es preguntar al programa por escrito antes de probar, o dejar el activo fuera. Una pregunta breve cuesta mucho menos que una disputa legal.

#Práctica: anotar una política de ejemplo y escribir una lista de verificación previa

Esta sección no necesita laboratorio. El programa de ejemplo que sigue es ficticio y usa el dominio reservado example.test. Vas a leerlo, marcarlo y revisar una lista de verificación con un pequeño script en tu propia máquina. Nada de esto envía solicitudes a un host real.

#La política de ejemplo

Guarda este texto como sample-policy.md en una carpeta vacía.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#Ejercicio de anotación

Copia la política en un archivo de texto y marca cada línea con una de cuatro etiquetas: [SCOPE], [RULE], [ASK] o [GAP]. Usa ASK cuando necesites aclarar algo con el programa antes de probar. Usa GAP cuando la política guarde silencio sobre algo que necesitas.

Luego responde por escrito a estas preguntas. Cita la línea que responde cada una y no respondas de memoria.

1. ¿api.example.test se rige por las mismas reglas que el sitio principal, o necesita una verificación propia?
2. ¿El límite de tasa aplica solo a los escáneres o también al tráfico manual?
3. ¿Cuál es la situación de payments.example.test y qué harías si una prueba llegara a él por accidente?
4. ¿El safe harbour cubre un hallazgo que expone datos de clientes?
5. ¿Qué parte de los términos de divulgación es un compromiso del dueño y cuál es una petición para ti?

La pregunta 4 no tiene respuesta en el texto. Márcala como GAP y escribe la pregunta que enviarías al programa.

#La lista de verificación previa

Escribe la lista antes de cada prueba. Debe caber en una pantalla, con una línea por elemento, tomada de las secciones de alcance, técnicas, cuentas, datos y contacto de la política. Guárdala como checklist.md:

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

Completa cada línea con la respuesta y, junto a ella, una cita de la política. Un elemento que no puedes completar es una pregunta abierta, y no debes probar hasta cerrarla.

#Revisa la lista con un script

Guarda el script de abajo como precheck.py en la misma carpeta. Lee un archivo de texto local y no se conecta a nada.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

Ejecútalo desde Git Bash, en la carpeta que contiene los dos archivos:

python precheck.py checklist.md
echo "exit=$?"

El autor lo ejecutó en una máquina con Windows 11 y Git Bash, con una lista en la que la línea de la cuenta de prueba todavía decía TBD. La salida fue:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

El verificador señala el elemento abierto y termina con estado 1, así que un script que lo llame puede detener la prueba. Solo comprueba que el formulario esté completo. No puede decir si una entrada coincide con la política, por eso cada entrada necesita la línea citada a su lado.

#Errores comunes

• Tomar el nombre del programa como alcance. Un programa llamado "Example Widget" puede cubrir un producto, varias empresas o ninguna de las subsidiarias que imaginas. Lee la lista.
• Probar un activo adivinado o heredado. Un subdominio que adivinaste, o una dirección de un registro público antiguo, está fuera del alcance hasta que la política lo liste.
• Ejecutar un escáner a máxima velocidad porque la política no habla de tasas. El silencio sobre las tasas no es permiso para ir rápido.
• Conservar datos después del reporte. Las copias que quedan en un portátil siguen siendo datos del dueño, y la política puede exigir borrarlas.
• Publicar pronto porque el proveedor respondió "corregido". Lee los términos de divulgación y espera a que se cumplan.
• Escribir un reporte que demuestra más de lo que tenías permiso para recolectar. El identificador y un campo censurado suelen demostrar el problema tanto como un volcado completo.
• Suponer que el safe harbour lo cubre todo. Cubre lo que dice su texto, para los sistemas que nombra.

#Cómo seguir avanzando

Practica el hábito de lectura con programas públicos que publican sus reglas. Mantén una lista de verificación por programa y relee la política el mismo día de la prueba, porque el alcance cambia. Lee completos el material de safe harbour de disclose.io y la página de divulgación coordinada de CISA. Aprende la diferencia entre una política de divulgación de vulnerabilidades, que puede no ofrecer recompensa, y un programa de bug bounty, que paga por los hallazgos. Luego lee cómo escribir tu primer reporte de seguridad para ver cómo debe presentarse un hallazgo cuando ya tienes permiso y ya encontraste algo.

Anota qué probaste, cuándo y desde qué cuenta. Si meses después surge una duda, esas notas son tu evidencia.

Desarrolla la parte técnica en un laboratorio aislado, no en el sistema de otra persona. Los pasos están en cómo crear una red Docker aislada para laboratorios. La información pública también tiene límites, que se tratan en ética y privacidad en OSINT.

#Fuentes

• disclose.io, safe harbour y herramientas de políticas: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• Departamento de Justicia de EE. UU., New Policy for Charging Cases Under the Computer Fraud and Abuse Act (mayo de 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act