Burp Suite is a great tool not because it contains all the needed features to test a service, but because it can be customized to perfectly fit the needs of each engagement. A common issue with my day-to-day when testing APIs is the need to pull a dynamic parameter from an initial request to then be used in the following requests. Unfortunately, the built-in macro capability in Burp Suite will only allow parameters in a specific format to be replaced in specific areas of the request.
This is where the Burp Suite extension Custom Parameter Handler fills the gap with the ability to modify any part of an HTTP request with nested levels of complexity. All that really means is I can perform an initial request and send the response to the next CPH rule to be handled and so on.
In this example, I will be hitting a Guild Wars 2 API, just for fun, to show how the extension works. The goal here is to search for a recipe from the API and send the returned integer to the next CPH rule to then process the output item id. This should return the crafting material we need to make the initial recipe.
First let’s install the Custom Parameter Handler from the BApp store under the Extender tab in Burp Suite.
This extension requires Jython so ensure you grab the latest standalone copy. Take note of the location you decide to place the file.
https://repo1.maven.org/maven2/org/python/jython-standalone/2.X.X/jython-standalone-2.X.X.jar
Configure Burp Suite to execute extensions that are written in Python with the newly-downloaded file.
Navigate to the Target > Scope configuration and check the “Use advanced scope control” check box. Add your desired Host or IP range. Here we use “guildwars2” to ensure requests sent to the GuildWars 2 API are correctly processed by the CPH extension.
Next, create or proxy the initial request that will be processed. In this example, you see I am providing a search input of “19726” with a response including a list of integers.
Right-click the response, navigate to Extensions, then Custom Parameter Handler, and send over to CPH.
Looking over at the CPH tab in the Burp Suite application click on the options tab. I highly recommend enabling the verbosity level to DEBUG while configuring the needed regular expressions. If not, you will have no way to identify where the match is failing. Ensure Repeater is also checked in the tool scope.
Below I have provided an example of some debug logs returned from the CPH extension. These can be found under the extensions tab, select the “Custom Parameter Handler” extension, and ensure the “Output” tab is selected.
Looking back at the initial request we can then configure the first tab of the configuration called GuildWars2CPH. First we set the scope using a regular expression looking for the “input=” followed by a 5 digit integer. Keep in mind that the global scope will trumph any regular expressions entered into this configuration so make sure you have the correct global scope configuration in place.
Next, we again use a regular expression to find the value you would like to replace followed by the value you would like to replace it with. Now since we are grabbing a value from the initial response, we enable the “The value I need is dynamic” checkbox and define a group item within a regular expression in section 4. This group item is then provided in section 3 to replace the value.
Navigating back to Repeater and performing the initial request now returns a different response including details about the provided recipe. Lets take a look at what is happening behind the scenes here.
Within the Logger tab we now see a single repeater request causes two requests within Burp Suite.
Last we want to return the cached response from GuildWars2CPH to then be processed by GuildWars2CPH-2. Looking back at the response received in repeater is a field named “output_item_id” with a value of “75784”. The goal here is to grab the value of that field and then form a new request to get retrieve information of that item.
In section 1 we again set the scope of execution to only requests containing the additional value meaning they have been altered by the first GuildWars2CPH tab. Next, we select the entire first row of the request because it will have to be significantly changed this time.
In section 4, we ensure we are using the results from the previous tab and set the group in section 5 to be provided in section 3.
Navigating back to the repeater tab and sending the initial request now results in a new response. This includes details about the item “75784” we grabbed after the first GuildWars2CPH configuration. Now lets see what happened in Logger.
Logger contains two logs showing the initial reponse followed by the last target response. All worked as expected.
Even though this example was rather useless, you can see the power behind this capability. Any value anywhere in the request/response can then be chained with multiple other requests for further testing. Tossing this request targeted by CPH over to Intruder and wow. Just do not forget to turn down the verbosity from the CPH configuration because that debug configuration will blow up.
This extension is now part of my daily use as a web application pentester and has proven to save massive amounts of time in testing. In addition, I can fully cover an API test with chaining CPH configurations without manually testing everything. Feel free to contact me on Twitter if you have any questions or concerns and until next time, stay safe in the Trenches of IT!