Good Report

Template Structure

Below is an example template. All sections should be updated to include correct information.

## 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).

Example

This is an example template:

# 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}}

Style Guide

Voice

Where possible, use passive voice. For example:

Correct:

An SQL injection vulnerability was discovered in the web application.

Incorrect:

I discovered an SQL injection vulnerability in the web application.

Incorrect:

Bugcrowd discovered an SQL injection vulnerability in the web application.

Incorrect:

We discovered an SQL injection in the web application.

Concision

Eliminate Redundancy

Incorrect:

Throughout the course of the engagement, a critical severity SQL injection was discovered in the web application (www.example.com) which could be used by an attacker to exfiltrate personally identifiable information from the backend database.

Correct:

An SQL injection was discovered in www.example.com allowing a malicious attacker to exfiltrate personally identifiable information.

Split Up Long Sentences

Incorrect:

An SQL injection was discovered in www.example.com allowing a malicious attacker to exfiltrate personally identifiable information including email addresses which would be considered a GDPR violation and poses a considerable business risk.

Correct:

An SQL injection was discovered in www.example.com allowing a malicious attacker to exfiltrate personally identifiable information. The retrievable data includes passwords, email addresses and full names. This poses a GDPR violation and considerable business risk.

Acronyms

When using an acronym, always spell out the full version first with the acronym in brackets. Once it has been spelled out in full, subsequent uses can just use the acronym.

For example:

Cross-Site Scripting (XSS) is a client-side attack which allows a malicious attacker to execute JavaScript in a victim's browser. XSS occurs when user input is reflected back to the browser without encoding.

Cross-Site Request Forgery (CSRF) was discovered in example.com. This CSRF allows you to update the victim user's address without their knowledge.

Spelling and capitalisation of common words

Correct: AoneM Incorrect: Aonem, aonem, Aone M, A one M .

Correct: pentest (or Pentest if grammatically required) Incorrect: pen test, PenTest, Pen Test

A vs. An

"An" should be used when the next word starts with a consonant sound. Otherwise, "A" should be used.

Correct:

• An apple

• An SQL injection

• An XSS

• An easy life

• A pineapple

• A vulnerability

Incorrect:

• An server

• A SQL injection

Emotive language

Language used should always be unemotive and impartial.

• Correct: Seven critical vulnerabilities were discovered.

• Incorrect: Seven concerning vulnerabilities were discovered.

• Incorrect: The overall security posture was very poor.

Researcher / Hacker / Attacker

• Use the word "researcher" when referring to a person who presents submissions to the SecurityT

• Use the words "attacker" when walking through an attack scenario, for example: "an attacker is able to exfiltrate customer data and perform arbitrary SQL queries".

• Never use the word "hacker".

Use of "victim"

• Don't use the word "victim".

• A good alternative is to refer to that person's role.

Examples:

• Incorrect: The vulnerability can be used to exploit the victim.

• Correct: The vulnerability can be used to exploit the user.

• Correct: The vulnerability can be used to exploit administrative users.

Placeholders

• {{target}}: Name of the in scope target listed on the program page (for example, *.aonem.com)

• {{application}}: A specific application within the target (for example, Acme Inc. Employee Portal)

• {{type}}: Type of testing performed listed next to the target on the program page (for example website testing, API testing, mobile application testing, hardware testing, etc.)

• {{url}}: Placeholder for a URL (for example, https://aonem.bxss.in/vulnerability)

• {{version}}: The specific version number of software tested (for example, 13.3.7)

• {{program}}: The program name (for example, AoneM)

• {{screenshot}}: Photo or video evidence displaying an execued proof of concept.

• {{action}}: The action that a malicious attacker could perform if they exploit it (for example, exfiltrate session tokens, take full control of administrative account, dump PII, etc.)

• {{parameter}}: A variable that transmits data from the client to the server which can have different types of data stored within them. The handling is determined by the server-side code. (for example id=1337)

• {{hardware}}: A specific piece of hardware used to exploit an IoT or Automotive asset

• {{software}}: A specific software used to exploit an asset (for example burp, nessus, nikto, etc.)

• {{payload}}: A command or payload that is executed on an asset

• {{value}}: A specific metric value (seconds, milliseconds, frequencies, etc.)

Good PoC

Issue type	PoC
Cross-site scripting	alert(document.domain) or setInterval`alert\x28document.domain\x29` if you have to use backticks. [1] Using document.domain instead of alert(1) can help avoid reporting XSS bugs in sandbox domains.
Command execution	Depends of program rules: Read (Linux-based): cat /proc/1/maps Write (Linux-based): touch /root/your_username Execute (Linux-based): id
Code execution	This involves the manipulation of a web app such that server-side code (e.g. PHP) is executed. PHP: <?php echo 7*7; ?>
SQL injection	Zero impact MySQL and MSSQL: SELECT @@version Oracle: SELECT version FROM v$instance; Postgres SQL: SELECT version()
Unvalidated redirect	Set the redirect endpoint to a known safe domain (e.g. google.com), or if looking to demonstrate potential impact, to your own website with an example login screen resembling the target's. If the target uses OAuth, you can try to leak the OAuth token to your server to maximise impact.
Information exposure	Investigate only with the IDs of your own test accounts — do not leverage the issue against other users' data — and describe your full reproduction process in the report.
Cross-site request forgery	When designing a real-world example, either hide the form (style="display:none;") and make it submit automatically, or design it so that it resembles a component from the target's page.
Server-side request forgery	The impact of a SSRF bug will vary — a non-exhaustive list of proof of concepts includes: reading local files obtaining cloud instance metadata making requests to internal services (e.g. Redis) accessing firewalled databases
Local file read	Make sure to only retrieve a harmless file. Check the program security policy as a specific file may be designated for testing.
XML external entity processing	Output random harmless data.
Sub-domain takeover	Claim the sub-domain discreetly and serve a harmless file on a hidden page. Do not serve content on the index page.

Good Report

# Writeups
# https://github.com/devanshbatham/Awesome-Bugbounty-Writeups

# Bug bounty Report

# Summary
...

# Vulnerability details
...

# Impact
...

# Proof of concept
...

# Browsers verified in
...

# Mitigation
...