Page 85 - Hands-On Bug Hunting for Penetration Testers

Unsanitized Data – An XSS Case Study Chapter 4

URL

This is the URL of the vulnerability. When executing test, code such as BMFSU , sometimes
it can be useful to alert a location (for example, BMFSU EPDVNFOU MPDBUJPO ). This way,
in a single screenshot, you can convey both preliminary proof of the bug and its location in
the application.

Payload

The XSS snippet we used to successfully execute JavaScript will go here. In the case of SQLi,
a successful password attack, or any number of other payload-based attacks, that data
would be required as well. If you trip on multiple payload types in one discovery, you
should mention however many illustrate the general sanitation rules being misapplied:
B PONPVTFPWFS BMFSU EPDVNFOU DPPLJF YYT MJOL B

Methodology

If you discovered the bug using a particular tool, tell them (and don't use a scanner if they
explicitly said not to!). It can help the team fielding your report validate your finding if they
use something similar and can incorporate that into reproducing the issue. In this case, we
would just say that we submitted the snippet and verified the bug manually.

It's also useful to list some basic info about the environment in which the vulnerability was
discovered: your operating system, browser type and version (plus any add-ons or
extensions if they're relevant), and any miscellaneous information you think is relevant (for
example, was it discovered in an incognito window? If using DVSM, Postman, or another
tool, did you use any particular headers?).

Instructions to Reproduce

Making sure your instructions are clear enough for the person that evaluated your report is,
along with the actual payload, the most important information you can provide. A
screenshot of the vulnerability (for example, the alert window) is great evidence, but could
easily fall short of winning you a payout if the issue can't be reproduced.

[ 70 ]