What is a security vulnerability?

Our industry has already created dozens of definitions explaining what a security vulnerability is. Instead of adding another definition to this list, we want to provide some guidance on how to analyze and report vulnerabilities.

First and foremost, when you believe that you have found a vulnerability and are preparing a report for us, please explain the following points in your own words:

  • Why you think the behavior is dangerous.
  • How the behavior affects the application in practice.

What this comes down to is providing a good attack scenario. When discussing whether something is or isn't a vulnerability, we focus on whether the attack scenario you provided in your report is something we would need to address or not (rather than evaluating if your report fits our definition of a "security vulnerability").

Common pitfalls when analyzing a potential vulnerability

One of the issues we often see is that bug hunters discover a behavior that is dangerous in some scenarios (and has a valid attack scenario), and then try to generalize it. An example of this is being able to upload files to a web server. In some cases, being able to do so might indeed be a vulnerability, but that doesn't mean that every website that allows you to upload files is vulnerable (think of Google Drive!). Being able to avoid invalid generalizations is also crucial when describing the impact a vulnerability might have beyond the few cases where it is dangerous.

This principle also applies to well-known vulnerabilities such as SQL Injection, XSS, and even RCE as Root! Some examples:

We discuss more examples of this type in the Invalid reports section of this site, e.g. Logout CSRF, Lack of X-Frame-Options, Lack of HSTS, or Open Redirects. These are some of the most common topics reported us, and they are usually found using automation. Unfortunately, automated tools can't describe a tailored attack scenario and we often receive copy/pasted descriptions of the vulnerabilities instead of an attack scenario.

Another common issue we have observed when discussing the merits of a report with bug hunters concerns the prerequisites of an attack, and how they can be distinguished from the consequences. For example, if you get code execution in a user's machine, you can steal their credentials. The point is that the consequences of many attacks are expected, acceptable, or unrealistic, and are always taken into account when evaluating a bug report.

These problems are summarized in a great video created by LiveOverflow which you can find at the end of this article.

As such, if we end up discussing whether something is a vulnerability or not, we'll usually point you to this page, and ask you to please help us understand your attack scenario instead :-).

  • What is a security vulnerability? – ft. LiveOverflow