Reporting for Penetration Testing REST APIs
Welcome back to the Penetration Testing REST API blog series for Part 3: Reporting. While often overlooked by security professionals, compiling reports is almost always required among penetration testers post-testing. That’s why today we’re going to review how to put all of our findings together and have a thorough paper trail.
If you missed part 1 and part 2 of the Penetration Testing REST APIs blog series, be sure to check them out before reading any further!
How Burp Suite can help with reporting Penetration Testing REST APIs
Using Burp Suite, it’s relatively easy to generate dumps of all the tests that were performed by using Intruder. Making it human-readable is another thing. In the Intruder window, select Save > Results Table. Burp Suite will generate a pop-up from which a number of options may be chosen. Here are my recommended configurations based on the attacks we performed:
Due to the nature of how we tested, Burp Suite isn’t able to automatically associate an intruder-based attack with a vulnerability and remediation strategy. So, unfortunately, it’s on us to parse the reviews manually and flag any anomalies worth including in a remediation strategy. To make the output file easy on the eyes, my recommendation would be to use Microsoft Excel, create a new spreadsheet, go to Data > from text/csv> and choose the output file we just created. From there, Excel should start an import wizard. Make sure you select “Edit” to verify the data has columns. Since some of our attacks include commas, we had to use tab as a delimiter. So, from the editing window choose “Split column,” and from the delimiter pull-down, make sure Tab is selected and hit OK. If it looks okay, hit close and load. We should now have a workable table that includes every attack we performed except for the repeater attacks, which I’ll get to in a minute.
Next, we need to include the server’s responses to each of these attacks. This is where our throttling comes from in part 1 of this blog series when we were configuring Burp Suite to slow down its automated scans. Although it adds a lot more testing time, it is 100% required if we want our server response packets in an order that matches the Request# from our first set of data from the attacks. To do this, from the Burp Suite Intruder window, select Save > Server Responses. Create a folder for the server responses and make sure “Concatenate to a single file” is NOT You’ll see why in a second.
In Excel, go to the Data tab again > Get Data > From File > From Folder. Select the folder we just saved the responses to and click OK. Make sure to click Edit when it shows us the import. On the Content column header, click the button circled in red below.
In the pop-up, choose on the delimiter pull-down to choose “Tab.” Then Click OK, then Save & Load. From here you should have a workable data-dump of every packet that you can now order in the “name” column which will match the Request Number of the previous data set. So now we have an exhaustive, sortable spreadsheet of all the attacks we attempted in the intruder scan.
Reporting on the repeater testing we performed is super easy. All we need to do is select the body of the request inside Burp Suite, right-click > Save Item. It’s that easy. Make sure to uncheck “Base64-encode requests and responses,” as this will ensure the packets are human readable. We’ll have to do this for all the requests of value that we used in the penetration test, but Burp Suite will save them as an XML file and they’re relatively easy to parse and include everything in both sent and received packets.
That should be it as far as generating our paper trail! Everything is accounted for and documented in our testing.
Although we only really focused on conducting SQL injection testing, you can use this blog as a logical guide with other tests such as Cross-Site Scripting and Cross-Site Request Forgery.
Both are excellent reads and I highly recommend them.
Conclusion
In conclusion I hope you enjoyed following along in this blog series learning about how to test these RESTful API services as more and more service providers keep promoting these interfaces. I think they’re wonderful personally, as they can extend so much functionality to the people who use them; however, as we just found out, testing them can require some extra steps. Feel free to comment on this blog or reach out to me on social media with any questions or comments! I really appreciate you taking the time to stop by and hopefully learn a thing or two about conducting your own, safe penetration tests on RESTful APIs using Burp Suite!
Penetration Testing Rest APIs Using Burp Suite Part 1
Penetration Testing Rest APIs Using Burp Suite Part 2
Learn more about how we can help bulletproof your apps with PenTesting
