We receive a non-negligible amount of submissions every day. We model the risk they represent for site owners, figure out what kind of privilege is required to successfully exploit the issue, and forward the information to plugin and theme authors to get it fixed.
This is can get pretty time-consuming, especially when we need to scavenge missing pieces of information ourselves. This is reflected in the time it takes us to handle submissions. The better the write-up, the faster it gets dealt with.
Here are a few tips and tricks to write better reports and help us accelerate the processing of your submission in the process.
Too Much Context Is Better Than None
Security bugs are naturally very contextual. Good knowledge of the context in which a vulnerability can be exploited is almost as important as the Proof of Concept (POC) exploit itself.
Here are some examples of the couple of questions we ask ourselves when reviewing submissions.
Who can exploit this vulnerability?
Is it exploitable by any visitor on the site? Does it require attackers to register an account at all? What kind of capabilities would that user need? (e.g., does it require a user set to the administrator role, or does the editor role work too?)
Generally, what we’re looking to know with those questions is twofold: finding out the minimum amount of privilege required to exploit this security flaw and modeling the risk it represents accordingly.
What does an attacker gain from abusing this bug?
The question is pretty straightforward, but sometimes the answer is not. It will often vary based on the minimum role required to exploit the vulnerability.
Generally speaking, we want to know more about what makes this vulnerability attractive to attackers. What advantages do they get from exploiting this bug? What added security risks does it represent for affected site owners?
In which circumstances can this be exploited?
This one is about the prerequisites for attacks to be possible. Some security bugs will require the presence of another third-party plugin for the vulnerable code to be run at all. Sometimes it’s only a problem if certain settings are enabled (or configured in a specific way!) on the administration panel. Are attacks only possible on certain days of the week?
This is all super important for us to know!
Where is the vulnerable code located?
If you know where the vulnerable snippet of code is, share it with us! This saves us a lot of time when it comes to communicating how to fix the issues with vendors.
What does a well-written POC look like?
It depends on the type of vulnerability. For simple URL-based reflected XSS issues, a single URL that runs some Javascript code is often enough.
Writing a good POC is pretty much like writing a recipe. Iterate through every step necessary to exploit the vulnerability. Here are a few examples of good POCs we received:
- https://wpscan.com/vulnerability/f27d753e-861a-4d8d-9b9a-6c99a8a7ebe0
- https://wpscan.com/vulnerability/47df802d-5200-484b-959c-9f569edf992e
If we’re dealing with more complex attacks, scripted POCs (PHP, Python, HTML forms in the case of CSRF attacks, etc.) work wonders as they give us clear, step-by-step instructions too. But don’t forget to add comments here and there so we know why it’s doing what it’s doing! 🙂
TL;DR
Don’t be scared to be too verbose! We’re looking forward to reading your submissions!
