We’re a whole month into 2021 already – and what a month it has been! Something that I always find fascinating is keeping an eye on the most common bug classes that get submitted through our platform. I think that having this knowledge can help to guide hunting efforts, to focus on the most common bugs.

In order to get the most common bug classes, I only included non-duplicate, valid bugs that are either P1, P2, P3 or P4. Because that’s what we’re looking for, right?

Let’s jump straight in!

10 – Remote Code Execution

Remote Code Execution occurs when an attacker is able to execute code on a target system in a way that is unintended. It’s hard to believe how common Remote Code Execution (RCE) vulnerabilities have been so far this year. The tenth most-common, in fact! There are many different ways to achieve RCE, but some ideas are:

  • Abusing file upload functionality to upload a webshell
  • Deserialization bugs
  • Exploiting known CVEs
  • Command injection

9 – Open Redirect

Open redirect bugs occur when an attacker is able to redirect an unwitting user to an arbitrary URL. It usually comes in the form of specifying a URL within a parameter, where the application will redirect to. As a basic example, if the “url” parameter on example.com was vulnerable to an open redirect, the following URL might redirect to https://bugcrowd.com.

https://example.com?url=https://bugcrowd.com

In a real attack scenario, an adversary might use this to host a phishing page to steal sensitive information, but overall this would require extensive user-interaction and social engineering, so without a chain, open redirects tend to be P4 priority.

Why are these so common? Because validating URLs is much harder than it seems.

A great resource for Open Redirect payloads, bypasses and techniques is https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect.

8 – Cross-Site Request Forgery (CSRF)

CSRF occurs where the user’s browser is tricked into performing unwanted actions on a vulnerable application. This is usually exploited by hosting malicious JavaScript payload on any attacker-controlled website and then convincing the user to navigate to it.

The JavaScript crafts a request to the vulnerable application that performs a sensitive request on the user’s account. The application accepts the request and performs the action, because no CSRF countermeasures were in place.

It’s difficult to understand why CSRF is still so common, there are many protections that can be implemented easily both at an application level and at a server level. Alas, they are still being found every day, and are often quite severe.

7 – Authentication Bypass

Authentication bypasses come in many forms. In recent years, authentication flows have become more complex in nature with the advent of SSO and third-party logins. Many applications now offer multiple forms of authentication, which can sometimes interfere with each other in unexpected ways. The implementation of these login methods require multiple steps and security considerations – each presenting an opportunity for exploitation.

To find these bugs, study up on OAuth, SSO, SAML, and other authentication flows. For the best understanding, try creating your own application using these flows! This will give you an excellent understanding of how these flows are supposed to work, so that you can spot inconsistencies more easily.

6 – Sensitive Information Passed to HTTP by Default

This is quite a simple one – it occurs when sensitive information such as passwords or session tokens are passed over cleartext HTTP instead of encrypted HTTPS. When this occurs, a well-placed attacker (man-in-the-middle) would be able to view the traffic in cleartext and use the sensitive information to their advantage.

According to our VRT, this type of vulnerability is usually a P4. It’s important to note that this is extremely easy to detect, which means that it will nearly always be a duplicate.

5 – Privilege Escalation

This is quite a generic bug class. It refers to any vulnerability that allows an attacker to gain higher privileges than they should be allowed. Some have argued that this bug class is so general that it covers almost every other bug class, which is true!

Privilege escalation comes in many different forms but most instances I’ve seen are closely related to access control bypasses. For example, a lower privileged user will be able to send a “create user” request and specify that the new user should be an administrator.

4 – Broken Access Control (including IDOR)

Again, “broken access control” is a generic term that we use to define any bug where a user is able to perform a function that should not be allowed to them. The most common example of this is Insecure Direct Object Reference (IDOR), where sensitive objects or functions can be accessed directly by people who should not have access. As a quick example, let’s say that we have an API endpoint that allows you to view your bank balance:

The “11111” is some kind of identifier for the user (such as an account number). In this case, a user should only be able to access their own bank balance, not the balance of other users. If we were able to access the following URL:

And the bank balance of user 22222 was returned – this would be considered an IDOR vulnerability. Time to report!

3 – Subdomain Takeover

So you thought subdomain takeovers didn’t exist anymore? I’ve got news for you! They’re everywhere! Every time an organization updates a DNS record, or removes a third party service, or lets a domain expire, there is potential for a subdomain takeover to exist. As you can imagine, this happens very regularly – especially in larger organizations.

For more information on subdomain takeovers, how to find them, and how to exploit them, my favourite resource is Patrik Hudak’s blog, start here (https://0xpatrik.com/subdomain-takeover-basics/). Another valuable resource is EdOverflows’s “Can I Takeover XYZ?” repository, which lists a bunch of services, and whether they are vulnerable to subdomain takeovers: https://github.com/EdOverflow/can-i-take-over-xyz. Finally, checkout codingo’s video on the topic: https://www.youtube.com/watch?v=q_A8aXLO1gA.

2 – Cross-Site Scripting

Cross-Site Scripting (XSS) is said to be discovered back in 2005 by Amit Klein. Sixteen years later, they’re still everywhere! This is because as a developer, mitigating against XSS is often a confusing task. Firstly there are three main types of XSS; stored, reflected and DOM based. Then there are many different contexts in which the injection might be reflected (e.g. in the base HTML, within script tags, within HTML attributes, in the <head> vs. <body>, in a file upload) each of these contexts requires different escaping/encoding.

There are many different ways to discover XSS vulnerabilities. Basic XSS bugs can often be discovered using automated scanners such as Burp’s active scan but due to the highly dynamic nature of XSS vulnerabilities, many of them can only be discovered through manual analysis.

1 – Sensitive data exposure

Sensitive data exposure refers to a bug where some type of sensitive data (secret keys, PII, passwords, etc.) are accessible in a way that they shouldn’t be. There are so many ways that this can happen, but some of the most common scenarios are:

  • Unsecured S3 buckets
  • Secret keys in client-side JavaScript
  • Passwords and secret keys in public Github repositories
  • Internal documentation exposed to the internet inadvertently

That just about sums it up! I really hope that this will help to focus your hunting efforts and get more bounties.

If you want to jump in and start hunting for these, check out Bugcrowd’s programs at https://bugcrowd.com/programs

If you have any technical questions, the best place to ask them is on Bugcrowd’s researcher Discord. I am personally active on there most days to answer questions.

Happy hacking!