Over the past year, we’ve spent some time diving into many of the different aspects relating to setting up a successful bug bounty program. Previously we’ve covered setting your scope, and the importance of focus areas, as well as some considerations to make around setting exclusions and provisioning your testing environment. Additionally, we’ve also taken a brief look at reward guidelines and disclosure policies, and how they can be used to both enhance your program and increase visibility.

In keeping with the greater theme, this post aims to briefly cover some key concepts in regards providing access your targets–including issuing credentials. As a quick refresher before discussing credentials, here are a few things to keep in mind in regards to your testing environment:

  • It’s important to remember that it should be our goal and intent to create as frictionless of an experience for researchers as possible–allowing us not only to attract great talent but also generate sustained activity and interest in our program. Additionally, at the same time, we also want to, as best we can, minimize the challenges of setting up and running a bug bounty for both you and your internal teams.
  • Similarly, it’s important to make sure that the test environment can stand up to the rigors of testing–including the use of scanners–by dozens, if not hundreds of concurrent testers. In this same vein, it also pays to be mindful and aware of any sensitive functionalities within your application that could potentially impact other elements of the organization if tested aggressively by researchers.
  • Testing in a staging environment can be an excellent way to avoid affecting production users and user data–helping ensure no production downtime, or contact with personally identifiable information/sensitive user data. For more pros and cons of each environment type, check out our blog post on setting up a testing environment.
  • Conversely, testing in a production environment is great if you have a large scope that extends to any property you own (see Tesla’s program). It is also ideal if you’re testing non-web applications (including open source applications), mobile applications or devices, or if it’s simply infeasible to set up a staging environment otherwise for the program. See more benefits of testing in production in our blog post.

So, when provisioning access (e.g. credentials), here are some best practices to keep in mind:

 

Best Practice #1: Don’t share…

Contrary to what your parents always told you, when it comes to credentials, it’s usually best not to share.

It can often be tempting set up just one set of credentials for all researchers to authenticate with and leave it at that. However, for those with strong imaginations, it’s easy enough to see how this can go wrong: the first researcher logs in, changes the password while testing the password change form for CSRF, and now nobody else can authenticate to the application.

At this point, the bounty has been effectively bricked, and all remaining researchers will take their talent and time somewhere where they can log in. Moral of the story: don’t fall into the trap of using shared credentials.

 

Best Practice #2: Provide researchers with the necessary tools to be successful…

Ultimately, you want researchers to find vulnerabilities. This is why we run bug bounty programs–so that we’re able to find these issues in the wild before someone malicious does. In this respect, your program is a success when researchers themselves are successful in finding vulnerabilities. So ultimately, we want to help researchers achieve success in any way we can.

Issue multiple credentials

In addition to avoiding shared credentials, generally speaking, we recommend that you provide each researcher at least two sets of credentials for every user level that you want them to test (e.g. two low-level users, two admins, etc.). Additionally, if you’re doing cross-tenant testing, you’ll likely want to include some from each tenant as well. This may sound a bit excessive, but in many cases, to validate a finding or to test a hypothesis, it’s incredibly helpful to have multiple accounts at every privilege level–allowing one to perform more comprehensive and accurate testing. For instance, if (as a researcher) you only have one low-level user account, and think that you might be able to update another user’s account information via an IDOR, it’s virtually impossible to verify this, since you only have the one account to test with. Rather than forcing the researcher to either ask for additional credentials or just abandon that attack vector, it’s best to provide them with all the tools they’ll need up front.

Consider testing restrictions

In the discussion around access, it’s also worth considering any access restrictions that your application may have–sometimes apps are geo-restricted, or have other factors that ultimately make it harder for all researchers to access it. Again, we want researchers to be testing against our program, and anything that inhibits their ability to do so also negatively impacts our full potential for success. To this end, prior to launching the program, we want to take into consideration these potential barriers, and provide solutions. In the case of geo-restrictions (e.g. only US-based ips can access the app), it’s worth setting up a small proxy box for international researchers to come through, enabling them to access and test against your app, etc. 

Provide supplemental information

Ultimately, the entire conversation on access is centered around this focal idea of providing researchers with the tools to be successful. It doesn’t just end at credentials or providing application documentation. Instead, take some time to look at your brief and ask yourself… If I knew nothing about this target, and the bounty is all the information I have to go off of, is it be enough for me to be successful as a tester? Is there a link to the API documentation? What about a setup guide? Would one need test credit cards (for full end-to-end testing through payment processing functionalities)? Fake bank accounts/SSNs/etc.?

In addition to having easy access to the application, it’s just as important that we provide researchers with the resources to be successful. Once more, when researchers are successful, you too are successful. Our goal should be to make it so easy and convenient to test on our application, that researchers have no reason to go anywhere else. 

 

Want to learn more about the ins and outs of running a successful bug bounty program? Here is a list of additional resources referenced in this post: