hakluke/bug-bounty-standardsUna lista de casos límite que ocurren en los programas de bug bounty y conversaciones sobre cómo deberían manejarse. El objetivo es estandarizar la forma en que se manejan situaciones específicas en los bug bounties.
Este repositorio es una lista de situaciones que ocurren en los programas de bug bounty y cómo deberían manejarse. Muchas de estas se manejan actualmente caso por caso, lo que genera mucha incertidumbre y frustración entre hackers, propietarios de programas y plataformas. El objetivo de este repositorio es estandarizar la forma en que estos casos límite se manejan en todas las plataformas y programas de recompensas. Con suerte, la estandarización permitirá que las expectativas se cumplan con más frecuencia por parte de todos.
Este documento es un borrador y aún no ha sido implementado por ninguna plataforma de bug bounty. En esta etapa, solicito comentarios de todas las partes interesadas.
Por favor, contribuye abriendo issues en GitHub. Todos los issues razonables enviados permanecerán abiertos durante un mínimo de 30 días para comentarios.
Tu issue debe expresar una opinión, por ejemplo:
Los comentarios sobre el issue son bienvenidos de cualquiera, pero deben ser constructivos y sin emociones. El comportamiento abusivo no será tolerado.
| ID | Situación | Resolución |
|---|---|---|
| 1 | El hacker envía una vulnerabilidad con prueba de explotación. La vulnerabilidad se corrige antes de que el envío sea triado. | La plataforma debe proporcionar una prueba de que el programa no accedió al envío antes de la resolución. Si el programa accedió al envío, el programa debe pagar la recompensa correspondiente; de lo contrario, el envío se marca como duplicado. |
| 2 | El hacker envía una vulnerabilidad y el programa responde diciendo que ya la conocía internamente. | El programa debe proporcionar una prueba de que se trataba de un problema conocido con anterioridad, por ejemplo, una captura de pantalla de un ticket de Jira con la fecha de creación. Si el programa no puede aportar la prueba, debe pagar la recompensa; de lo contrario, el envío debe marcarse como duplicado. |
| 3 | El hacker envía una vulnerabilidad que se marca como duplicado de otro envío que no exploró por completo el impacto del bug. Por ejemplo, un hacker envía un XSS completo que permite la toma de control de la cuenta y se duplica contra otro envío que solo reportaba inyección de HTML. | El primer reportero recibe una recompensa según el impacto de su envío; el segundo reportero recibe una recompensa según el impacto de su envío menos la recompensa recibida por el primer reportero. |
| 4 | El hacker envía una vulnerabilidad y el programa nunca responde. | La plataforma paga la recompensa. |
| 5 | El hacker envía una vulnerabilidad y se le duplica incorrectamente contra un informe más reciente. | La plataforma cambia el estado de ambos informes para que sea preciso. Si el pago ya se ha realizado incorrectamente, la organización que hizo el triaje incorrecto paga la recompensa. En los programas de recompensas gestionados, esto generalmente sería la plataforma, pero en los programas no gestionados sería el programa. |
| 6 | El hacker no está de acuerdo con la clasificación de severidad asignada. | El hacker envía su razonamiento al ticket. Si no hay respuesta en 14 días, el hacker envía el razonamiento al canal de soporte de la plataforma. Las mejoras de severidad se deciden caso por caso. |
| 7 | El hacker divulga públicamente un bug que ha sido enviado previamente a la plataforma, sin permiso explícito del propietario del programa. | Un investigador debería poder divulgar públicamente la vulnerabilidad bajo las siguientes circunstancias: a) El bug no ha sido aceptado como válido, es decir, ha sido marcado como N/A o Informativo. b) El bug ha estado en estado resuelto durante 30+ días. c) El investigador tiene permiso explícito del programa para divulgar públicamente. En otros casos, el hacker recibe una suspensión de 30 días de la plataforma, y se le envía un correo con el razonamiento completo de la suspensión. La reincidencia resulta en una suspensión permanente. |
| 8 | El hacker envía un bug que está dentro del alcance del programa, pero en realidad es un bug en un servicio de terceros. | Cada programa debe especificar si acepta bugs en sistemas de terceros dentro de su brief. Si no hay especificación, se asume que TODOS los sistemas enumerados en el alcance serán válidos para el pago, incluidos los sistemas de terceros. |
| 9 | El hacker envía una vulnerabilidad de día cero sin exploits ni divulgaciones públicas existentes, que afecta a sistemas dentro del alcance. | Si se realizó algún cambio como resultado del informe, es decir, cambios de configuración, poner sistemas fuera de línea o aplicar reglas de WAF, el informe debe aceptarse y recompensarse. Hay que distinguir entre exploits de día cero que son públicos y exploits de día cero que tu equipo no habría conocido si no fuera por el informe de bug bounty. |
| 10 | El hacker envía un bug a un programa que tiene un brief de alcance abierto. El bug está en una adquisición. El propietario del programa no controla la infraestructura de TI ni el personal de la adquisición. | El propietario del programa debe hacer un esfuerzo de buena fe, verificado por la plataforma, para informar a la adquisición. Si la adquisición se beneficia del envío, el propietario del programa debe pagar la recompensa. El brief debe actualizarse para reflejar si la(s) adquisición(es) está(n) dentro del alcance. |
