bugcrowd/templatesRepositorio para albergar plantillas de markdown para investigadores
Notas sobre la estructura de directorios:
El script generate-directories.py obtiene la versión más reciente de la estructura VRT desde GitHub y crea los directorios que falten. No elimina ni renombra directorios basándose en elementos eliminados de VRT.
El script sigue los nombres de entrada estándar y conserva los guiones bajos / mayúsculas y minúsculas tal como los proporciona el campo id de VRT.
Este repositorio tiene habilitado 'Master protegido'; lo que significa que solo los administradores del proyecto pueden hacer commit a la rama master, mediante Pull Requests. Todas las actualizaciones deben llegar a través de un pull request para garantizar la integridad.
Lo siguiente está escrito asumiendo que el acceso SSH está correctamente configurado.
Primero, descarga la rama master:
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
Una vez que tengas master en tu sistema, deberás crear una rama para el trabajo que vas a realizar:
git checkout -b <branch-name>
Ejemplos de nombres de rama podrían ser XXE-templates, XSS-templates, algo que indique qué lote de trabajo es. Deben mantenerse pequeñas, preferiblemente un grupo de plantillas y no mucho más. ¡Haz commit y push con frecuencia!
git commit -am "Comments about what you changed go here" guarda tus cambios en el repositorio git local. Siempre deja un mensaje de commit descriptivo.
Cuando hayas completado tus plantillas, puedes hacer push de ellas al repositorio. Estas seguirán en su propia rama, pero al hacer push se ejecutará el linter y validará el markdown contra un conjunto de reglas. Si seguiste la plantilla de ejemplo y no te desviaste mucho, las plantillas deberían pasar.
git push --set-upstream origin <branch-name> Esto creará la rama en el servidor origin (github) y subirá tus cambios. Esto solo necesita hacerse una vez para la rama, y los push posteriores de la rama se pueden realizar con git push.
Una vez que el linter se haya ejecutado correctamente, puedes crear un Pull Request (PR).
Selecciona la rama en la interfaz de GitHub. Deberías ver un botón 'Pull request' sobre el código.
Selecciona ese botón, luego completa algunos detalles sobre lo que cambió para que los administradores del proyecto lo revisen y haz clic en 'Create pull request'.
En ese punto, ¡has terminado! Revisaremos el PR y lo fusionaremos o rechazaremos según corresponda.
Una vez que el PR sea aceptado, puedes eliminar la rama libremente.
git branch -d <branch-name>
A continuación se muestra una plantilla de ejemplo. Todas las secciones deben actualizarse para incluir información correcta.
## Overview of the Vulnerability
Provide a 1-2 sentence description of the vulnerability.
This format is a good guide:
[VULNTYPE] in [COMPONENT] in [APPLICATION] allows [ATTACKER] to [IMPACT] via [VECTOR]
## Business Impact
Provide an example of the impact to the business. This could be reputational damage, financial loss, a loss in customer trust, etc.
## Steps to Reproduce
Provide a step-by-step walkthrough on how to access the vulnerable injection point, and how to exploit the vulnerability.
Example:
1. Login to in-scope asset at <www.bugcrowd.com/login>
1. Browse to account page
1. Modify ID token to add single quote
1. View error which states 'SQL Syntax Error'
1. Replace ID value with `1' waitfor delay '00:00:10'; `
## Proof of Concept (PoC)
Your submission must include evidence of the vulnerability and not be theoretical in nature.
You may present your evidence as output from a tool, such as SQLMap, unless the program forbids the use of these tools. Evidence may also be in the format of terminal output, screenshots, or video.
Use this section to demonstrate clearly the effect of the vulnerability. However, do not access Personally Identifiable Information (PII).
Esta es una plantilla de ejemplo:
# Reflected Cross-Site Scripting (Non-self)
## Overview of the Vulnerability
Reflected Cross-Site Scripting (XSS) is a type of injection attack where malicious JavaScript code is injected into a website. When a user visits the affected web page, the JavaScript code executes and its input is reflected in the user’s browser. Reflected XSS can be found on this domain which allows an attacker to create a crafted URL. When opened by a user, this URL will execute arbitrary Javascript within that user’s browser in the context of this domain.
When an attacker can control code that is executed within a user’s browser, they are able to carry out any actions that the user is able to perform, including accessing any of the user's data and modifying information within the user’s permissions. This can result in modification, deletion, or theft of data, including accessing or deleting files, or stealing session cookies which an attacker could use to hijack a user’s session.
## Business Impact
Reflected XSS could lead to data theft through the attacker’s ability to manipulate data through their access to the application, and their ability to interact with other users, including performing other malicious attacks, which would appear to originate from a legitimate user. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.
## Steps to Reproduce
1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
1. Use a browser to navigate to: {{URL}}
1. Forward the following request to the endpoint:
```HTTP Request
{{request}}
```
1. Observe the JavaScript payload being executed
## Proof of Concept (PoC)
Below is a screenshot demonstrating the injected JavaScript executing at the vulnerable endpoint:
{{screenshot}}
Cuando sea posible, usa voz pasiva. Por ejemplo:
Correcto:
Se descubrió una vulnerabilidad de inyección SQL en la aplicación web.
Incorrecto:
Descubrí una vulnerabilidad de inyección SQL en la aplicación web.
Incorrecto:
Bugcrowd descubrió una vulnerabilidad de inyección SQL en la aplicación web.
Incorrecto:
Descubrimos una inyección SQL en la aplicación web.
Incorrecto:
Durante el transcurso del trabajo, se descubrió una inyección SQL de severidad crítica en la aplicación web (<www.example.com>) que un atacante podría utilizar para exfiltrar información de identificación personal de la base de datos backend.
Correcto:
Se descubrió una inyección SQL en <www.example.com> que permite a un atacante malintencionado exfiltrar información de identificación personal.
Incorrecto:
Se descubrió una inyección SQL en <www.example.com> que permite a un atacante malintencionado exfiltrar información de identificación personal, incluidos los correos electrónicos, lo que se consideraría una violación del GDPR y plantea un riesgo comercial considerable.
Correcto:
Se descubrió una inyección SQL en <www.example.com> que permite a un atacante malintencionado exfiltrar información de identificación personal. Los datos recuperables incluyen contraseñas, correos electrónicos y nombres completos. Esto supone una violación del GDPR y un riesgo comercial considerable.
Cuando uses un acrónimo, escribe siempre la versión completa primero con el acrónimo entre paréntesis. Una vez que se ha escrito completo, los usos posteriores pueden emplear solo el acrónimo.
Por ejemplo:
Cross-Site Scripting (XSS) es un ataque del lado del cliente que permite a un atacante malintencionado ejecutar JavaScript en el navegador de una víctima. XSS ocurre cuando la entrada del usuario se refleja de vuelta al navegador sin codificación.