One of the primary ways to find security vulnerabilities in an API is to get it to work in ways the developer did not expect or intend. You can usually achieve this by tainting data in weird places, as I’ve discussed before.

Discovering hidden inputs can offer additional opportunities to induce unintended behaviors in the APIs you are testing. This is especially true when you can detect parameters that aren’t well documented, if documented at all. 

These hidden API parameters are a good indicator of potential code flow you can manipulate that the developer doesn’t want you to know about. And definitely doesn’t want you to alter. 

That’s probably why the developer hid them.

In this article, I will show you how to find these hidden parameters in the APIs you are hacking.

What exactly is a “parameter”?  

In the context of APIs, a parameter is a variable or placeholder that serves as an input to an API endpoint, allowing users to pass specific data to influence the API’s behavior. 

Parameters can be included in the URL as query parameters or in the request body. They can also include special headers or even be part of the request path. 

They help define the specifics of the API request, such as filtering results, specifying resources, or providing metadata for authentication or authorization. 

Proper handling and validation of parameters are crucial for ensuring the security and functionality of the API. When they aren’t handled properly, they become a perfect attack vector for us to abuse during security testing.

Finding hidden API parameters through fuzzing

The concept of fuzzing may or may not be new to you. It involves sending a wide range of unexpected, random, or malformed inputs to test how the system responds. 

Fuzzing usually aims to identify vulnerabilities, such as buffer overflows, input validation issues, or hidden functionalities that your adversaries could exploit.

This same concept can be used when looking for hidden API parameters. It works by injecting numerous potential parameter names into HTTP requests to see how the server responds.

By analyzing the API’s responses to these injected parameters, you can look for changes in the behavior or content of the response that indicates the parameter is being processed or has an effect on the endpoint.

This can be labor intensive and tedious. However, some tools can help automate this process. One of my favorites is a Burp Suite extension called Param Miner.  

Param Miner

Portswigger publishes a Burp Suite extension called Param Miner that is designed to automate the discovery and fuzzing of hidden parameters in web applications and APIs. It systematically injects a variety of common and potentially useful parameter names into HTTP requests, analyzing the server’s responses to detect any changes in behavior or content that indicate the parameter is recognized and processed. 

By leveraging both brute force and dictionary attacks, Param Miner efficiently tests a wide range of potential parameters. Additionally, it employs heuristic analysis to identify subtle patterns or anomalies in the responses that may suggest the existence of undocumented parameters. 

This automation significantly reduces the manual effort required for parameter discovery, making it an invaluable asset for security testers aiming to uncover hidden functionalities and potential vulnerabilities in an API.

Using Param Miner for the first time

Once you install Param Miner directly from the BApp store, it’s available to you from pretty much any request or response within Burp Suite. 

Right-click on an HTTP request and select Extensions > Param Miner > Guess Params. This will bring up a menu offering you to have Param Miner to guess “GET params”, “cookie params” or even “headers”.  You can also try to guess params across all three input vectors by selecting “Guess everything”, which is my preferred method.

Once you select the desired method for fuzzing with Param Miner, it will prompt you with an Attack Config dialog box. I highly recommend you leave the default settings configured unless you know exactly what you are doing.

PortSwigger hasn’t documented the attack configuration. However, if you want to understand what it does, some rudimentary third-party documentation may help, which you can read here.

The one configuration option to consider overriding may be the “use custom wordlist” checkbox along with the “custom wordlist path” if you wish to use your own. However, you will find that the default wordlist that the extension uses includes over 50,000 common parameter names. An alternative you might want to try is SecList’s burp-parameter-names.txt, which has about 6,500 of the most common parameters. 

Once you are ready to begin the parameter fuzzing, hit OK and let Burp Suite go to work behind the scenes.

TIP: If you select “Guess Everything,” you may notice that you have to click the OK button several times. That is an expected behavior. It shows a new Attack Config for each param guessing strategy it uses, but the UI doesn’t do a great job explaining that.

Analyzing results

Once you start the fuzzing, there are two ways to see results. The first is to go to the Extensions tab, select the “Installed” subtab, scroll down to the Param Miner extension and select it. You can now click on the Output tab and look for log records starting with “Identified parameter”.

If you own Burp Suite Professional, you can also find the results in the “Issues activity” on the Dashboard or in the Target Sitemap. Detected inputs will be denoted as “Secret Input” in the Issue Type. 

Stopping a fuzzing session

When using the default attack configuration, fuzzing could literally take hours, if not days. You might not notice it, as Param Miner runs quietly in the background, but it just carries on without a care unless you stop it.

There is no clean way to stop or pause an active fuzzing session directly within the extension or the Burp Suite UI.

One way to force it to stop is to completely unload the Param Miner extension from the Extensions tab. 

Don’t remove the extension; instead, click the checkbox that says “Loaded” to force Burp Suite to unload it, ultimately stopping code execution. 

When this happens, you will see an exception and error message that says “Extension unloaded—aborting attack,” but it’s harmless. Param Miner has a built-in kill switch that properly closes everything as it unloads.

Rate limiting your fuzzing

One of the first things you will learn about Param Miner is that it’s an aggressive fuzzer. Left to its own accord, it will flood the target with requests. You can watch this live by going to the Logger tab.

This probably won’t be acceptable on production targets. To avoid this, you will want to slow down the requests before you get rate limited, which isn’t something you can natively do inside of Burp Suite.

But like anything in Burp Suite, there is an extension for that which can help. It’s called Distribute Damage.

Distribute Damage

Designed to help Burp Suite evenly distribute load across multiple scanner targets, the Distribute Damage extension introduces per-host throttling and a global pause button for all extensions. It also helps avoid detection.

In the past, I’ve written about discovering an API’s “Rate Limit Window & Ceiling” and its importance for understanding the threshold. Then, you can dial back the requests accordingly by adjusting the timing throttle, which is in milliseconds between requests. 

The configuration looks something like this:

TIP: This config only impacts things that are automating requests, like the web vulnerability scanner, all extensions, and tools like Intruder. It will not affect normal browsing going through the attack proxy or even requests sent by the Repeater tool.  

Advanced API fuzzing against JSON payloads

There is one lesser-known feature of Param Miner that is great for API hackers. That is because it can also inject fuzzing directly into JSON payloads. So when you encounter a request that includes a JSON body, consider fuzzing for properties within the object that may be accepted. This is exactly how the vulnerability class around Mass Assignment can be abused.

To trigger JSON fuzzing like this, right-click on an HTTP request and select Extensions > Param Miner > Guess Params. You will notice a new special menu item that says “Guess JSON parameter.” Click it and configure the Attack Config, as discussed earlier in this article. 

TIP: Consider the impact of testing like this. You could be creating or updating tons of records within the API. When possible, conduct this sort of fuzzing on staging or demo instances you have control over. 

I also suggest you use a more customized wordlist that is more in tune with the JSON schemas you discovered during your recon, along with common JSON property name wordlists.

Conclusion

Discovering hidden API parameters is a critical skill for identifying and exploiting potential security vulnerabilities. 

By leveraging techniques like fuzzing and utilizing tools such as Param Miner, API hackers can systematically uncover undocumented and hidden parameters that developers may have overlooked. 

These hidden parameters often provide unique opportunities to manipulate the API in unintended ways, revealing potential security flaws. As illustrated, automating the process with tools like Param Miner significantly reduces the manual effort involved, making conducting thorough security assessments easier and more efficient. 

So give Param Miner a try. You might be pleasantly surprised by what you find.

Good luck!

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. 
If you haven’t, subscribe today at https://apihacker.blog.

The post Finding hidden API parameters appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/finding-hidden-api-parameters