Mastering Small Scope Programs: A Comprehensive Guide for Bug Hunting

Hi there, I hope you’re all doing well. This is my fourth writeup, and today I will discuss how to approach small scope programs. By small scope programs, I mean programs that have no wildcards such as:

• test.com and api.test.com in scope , etc

We will start off by creating an account on platform and logging in. With Burp Intercept On, now your work is to check every functionality and click every link you see. You can perform CRUD operations which are available on such functionalities , while you are doing that Burp Suite will populate the SiteMap which means we will be identifying many endpoints with different parameters which we can later test on.

Before we go further, some of you might already be uninterested in testing the website or might find it boring. However, I would suggest dedicating at least eight hours before moving on to another program. In these eight hours, you will learn the application’s purpose, its various functionalities, and how they are supposed to work.

To start off, you can first learn about the purpose of the web application itself. For that, you need to find out :

• If they have published any blogs
• If they have a Youtube channel (which can sometimes be a treasure trove)
• If they have documentation (which can be a gold mine)

This is where the fun begins, once you start getting familiar with your target you will notice that you are enjoying it actually and there will be some positive results soon if you stay persistent. Lets assume you know the purpose of most of functionalities and the application and now you are ready to take off.

One At a Time:

Test functionality one at a time, try to perform CRUD (Create Read Update DELETE) operations on every endpoint . Assuming /v1/user/12345 is the endpoint then we can perform each operation like this :

• Create: POST /v1/user HTTP/1.1
• Read: GET /v1/user/12345 HTTP/1.1
• Update: PUT /v1/user/12345 HTTP/1.1 , sometimes PATCH is used to update also but it depends on what they have implemented
• DELETE /v1/user/12345 HTTP/1.1

Note that the POST, PUT,PATCH methods require HTTP parameters with correct value in request body so the backend can process your requests. Lets say to create a user we can issue the following HTTP request on test.com

POST /v1/user HTTP/1.1
Host: test.com
Content-Type: application/json
Authorization: Bearer your_access_token

{
    "username": "newUser123",
    "password": "passw0rd",
    "email": "newuser123@test.com",
    "firstName": "New",
    "lastName": "User"
}

it will create a User with given “username”,“password” , “email”, “firstName” and “lastName” values .

Also if there is any error after you issue HTTP request, the response might contain additional detail of what went wrong:

• missing “location” parameter, if you see error like this usually it means you need to add a location parameter
• “password” must contain alphanumeric characters, the value you passed in password parameter needs to be alphanumeric, etc

But these are just the basics, and you will learn eventually if you keep learning every day.

Same thing with DELETE requests, just

DELETE /v1/user/1337 HTTP/1.1
Host: test.com
Authorization: Bearer your_access_token

If it goes through and user with “userId” 1337 is deleted then you are lucky to have found a serious vulnerability.

Many times, you have no idea if the endpoint supports other HTTP request methods and since you don’t test other methods , you end up loosing a lot of bugs.

Suppose you only see PUT /v1/user/123445 endpoint to update other users but what you don’t know is it might be supporting PATCH /v1/user/123445 which means maybe you can add extra params or find IDOR with PATCH if PUT is not vulnerable since the logic for both can differ.

So you should test every endpoint with different HTTP request methods so you don’t miss any vulnerabilities.

Note: POST/PUT/PATCH methods can require a valid Content-Type header , in this context it is Content-Type:application/json . I am pointing this out because often the websites will reject your request with 400 response if the correct Headers with values are not sent along so you will think that the endpoint is not vulnerable just because you forgot to set right HTTP headers and values within the request.

Hunting for CSRF :

Usually most hunters simply check for CSRF protection in a request and after they have tried everything they can to bypass that particular endpoint then they give up and look for other bugs. But the truth is every endpoint need to be evaluated with every possible bypass you think there is to find that one vulnerable endpoint. Yes its true that some endpoints might not be validating it so you should check all of them, better automate .

There are many CSRF bypass techniques available on twitter, hackerone reports, etc which you can easily find by googling.

Hunting for XSS:

Context of reflection of payloads matter in this case. Most of hunters just blindly spray the payload without understanding where the payload is injected, elements, js context, etc. So let’s say you are trying to inject an XSS payload on “name” field and it does not reflect and you think its not vulnerable but the “name” field might be reflected somewhere else too within the application which you need to find and this time maybe the developer forgot to sanitize the input and XSS will occur.

Mass Assignments:

It occurs when an application blindly copies user-controlled input into model properties, permitting an attacker to modify any property of the model.

Let’s look back at the HTTP request to create an account:

POST /v1/user HTTP/1.1
Host: test.com
Content-Type: application/json
Authorization: Bearer your_access_token

{
    "username": "newUser123",
    "password": "passw0rd",
    "email": "newuser123@test.com",
    "firstName": "New",
    "lastName": "User"
}

Here everything looks normal, but what if you add a new parameter “userId” with value 1337 like :

POST /v1/user HTTP/1.1
Host: test.com
Content-Type: application/json
Authorization: Bearer your_access_token

{
    "username": "newUser123",
    "password": "passw0rd",
    "email": "newuser123@test.com",
    "firstName": "New",
    "lastName": "User"
    "userId":1337
}

Assuming that the user with 1337 userId already exists and we are trying to create a new account with this userId,

(i) Will it create a new user account with 1337 userId and delete the user account?

(ii)Will it update the user 1337’s mail and password leading to ATO

Either way, if the application processes and creates a user with 1337 userId, its a vulnerability itself as it can delete to account deletion of victim or worst case ATO which are both critical in nature.

You can use tools like Param Miner from BApp Store to fuzz and identify new parameters in request body and validate them manually.

Or you can use Open source tool by Somdev Sangwan : https://github.com/s0md3v/Arjun to do same if you don’t happen to have burp suite professional.

Mass Assignments are common in API and sometimes are Critical.

Excessive Data Exposure:

Unlike GraphQL, REST APIs are known for disclosing excessive data than needed.

For example , you are Owner of Org A and you invited User B, User B joins your Organization. Assuming User B ,”userId” is 1337 Now you try to read User B :

GET /v1/user/1337 HTTP/1.1
Host: test.com
Content-Type: application/json
Authorization: Bearer your_access_token

and its response is :

HTTP/1.1 200 OK
Date: Fri, 05 Aug 2023 19:45:31 GMT
Server: Apache/2.4.37
Content-Type: application/json
Content-Length: 300
Connection: keep-alive

{
  "id": 1337,
  "username": "JohnDoe",
  "email": "john.doe@example.com",
  "firstName": "John",
  "lastName": "Doe",
  "age": 30,
  "height": "180 cm",
  "location": "New York, USA",
  "postalAddress": "10021-3100 New York, Park Ave",
  "passportNumber": "123456789",
  "created_at": "2021-08-05T14:45:31.000Z"
}

As you can notice, it is disclosing personal information of 1337 user which are meant to be private since it is PII. These parameters are disclosing personal information:

"age": 30,
"height": "180 cm",
"location": "New York, USA",
"postalAddress": "10021-3100 New York, Park Ave",
"passportNumber": "123456789",

This is one example, but you have to check every endpoint response to see if it is disclosing some extra sensitive information such as PII, Api Keys, Session Tokens, etc

Finding more hidden endpoints/parameters:

Unauthenticated or Authenticated, Javascript files and Page Source etc can contain more endpoints, more parameters which might/might not be used in the application. You can use tools like JS Link Finder from BApp Store as it does an excellent job in uncovering those endpoints/parameters.

Or You can use LinkFinder by @GerbenJavado : https://github.com/GerbenJavado/LinkFinder

or any alternative tool which is available

Doing so will help you discover new endpoints/parameters that could potentially be vulnerable.

Reading the Documentation:

As I said earlier, it’s a gold mine. Documentation contain everything you need to know on how to implement, the usecase, etc .

Its a weapon you can use to find bugs, let’s see the documentation says “Only Owner can invite users” , now you can try to invite a User from Admin role account and if it works then its a vulnerability which can be reported. In report , you should reference the phrase where its written “Only Owner can invite users” along with documentation link so its easy for them to validate and triage vulnerability.

This is just a one case which I am mentioning, you should read every line of documentation so that you don’t miss some useful information. If documentation says you cannot do something then you should try to validate it.

Keeping yourself up to date:

By now, you have probably found many bugs in your program if you were persistent and spent a good amount of time to study it. You are going to top the leaderboard soon if you keep going and you feel like you are done with the program . There will be a moment where you will be satisfied with the amount of time you spent and the results and you would want to move into other programs, but before moving on, you should :

• Fork their API collection from postman to your workspace if they have one and enable notifications so that if any changes are made: new endpoints, parameters, added/removed then you are notified
• Follow them on Twitter, if they have twitter handle you can follow them on twitter so that you keep yourself updated with what new feature they have added while you scroll twitter
• Subscribe their newsletter, so you get updates
• Keep eye on their change log if they have one
• Subscribe their program on Hackerone or other platforms where you hunt so that you will get updates if a new scope is added, allowing you to hunt on fresh targets before others.

Continued Learning and Development:

Learning new concepts about different vulnerabilities will help you keep updated and expand your vulnerability checklist

I recommend the Portswigger Web Academy: https://portswigger.net/web-security/dashboard

Portswigger Research: https://portswigger.net/research

They are completely free and you don’t need to spend a penny on cheap bug bounty courses.

Everything is available online , there are amazing blogs by amazing people. You should follow your mentors/idols on twitter or on relevant social medias so you can learn from what they share.

You should also learn/read new security concepts from the other writeups, blogs, disclosed reports, etc.

Final Words

• Everything is free on internet, its an ocean where you can swim unless you don’t know ofc😂 but eventually you will learn xD
• Stay Persistent, don’t get distracted. Even a bit of progress every day counts.
• Take care of health too
• Finally you should :

Rather than just scrolling twitter daily and waiting for someone to mentor. Remember If you cannot help yourself, no one can. Those who are successful now were persistent; they were eager to learn and had a vision. This is the way.

How you are supposed to find vulnerabilities if you just give up in some minutes or some hrs, or the worst is doing nothing and sitting just thinking lol.

It requires persistence ,patience and determination. Don’t give up easily, it might take months, years. Remember Duplicate reports are part of the process .

Every failed attempt is a step towards success. Every bug that you don’t find gets you closer to the bugs you will eventually find. Treat every ‘failure’ as a learning opportunity.

And Of course I didn’t cover SQLI, SSRF, etc other categories as I believe most of you are familiar with these categories. You should try everything on each parameters and verify how they are handling inputs and check for different vulnerabilities.

I believe I covered some basic topics in this writeup. I did not cover much recon as we dived into the application and I hope they are helpful to the community. I might add more based on the feedback I receive from the readers.

Thank you for reading!