21 March, 2019

Better API Penetration Testing with Postman – Part 2

Better API Penetration Testing with Postman – Part 2
Mic Whitehorn
Author: Mic Whitehorn
Share:
In Part 1 of this series, I walked through an introduction to Postman, a popular tool for API developers that makes it easier to test API calls. We created a collection, and added a request to it. We also talked about how Postman handles cookies – which is essentially the same way a browser does. In this part, we’ll tailor it a bit more toward penetration testing, by proxying Postman through Burp. And in the upcoming parts 3 and 4, we’ll deal with more advanced usage of Postman, and using Burp Extensions to augment Postman, respectively.
 

Why proxy?

By using Postman, we have its benefits as a superior tool for crafting requests from scratch, and managing them. By proxying it through Burp, we gain its benefits: we can fuzz with intruder, we have the passive scanner highlighting issues for us, we can leverage Burp extensions as we will see in Part 4 of this series. And we can use Repeater for request tampering. Yes, it’s true that we could do our tampering in Postman. There are two strong reasons to use Repeater for it: 1) Postman is designed to issue correct, valid requests. Under some circumstances, it will try to correct malformed syntax. When testing for security issues, we may not want it trying to correct us. 2) By using Repeater, we maintain a healthy separation between our clean-state request in Postman, and our tampered requests in Repeater.

Setting up Burp Suite

An actual introduction to burp is outside the scope of this particular post. If you’re reading this, it’s likely you’re already familiar with it – we aren’t doing anything exotic or different for API testing.
If you’re unfamiliar with it, here are some resources:

example 1

Now, launch Burp, check the Proxy -> Options tab.
The top section is Proxy Listeners, and you should see a listener on 127.0.0.1, port 8080. It must be Running (note the checkbox). If it’s not running by default, that typically means the port is not available, and you will want to change the listener (and Postman) to a different port. As long as Burp is listening on the same port Postman is trying to proxy through, your setup should work.

example 2

Also check the Proxy -> Intercept tab and verify that Intercept is off.

Configuring Postman to Proxy through Burp

Postman is proxy-aware, which means we want to point it at our man-in-the-middle-proxy, which is Burp Suite (my tool of choice) for this post. We’ll open the Settings dialog by clicking the Wrench icon in the top-right (1) and then Settings option on its drop-down menu (2).
This will open a large Settings dialog with tabs across the top for the different categories of settings. Locate the Proxy tab and click it to navigate.

example 3
Opening the Postman Settings pane

There are 3 things to do on this tab:

  1. Turn On the Global Proxy Configuration switch.
  2. Turn Off the Use System Proxy switch.
  3. Set the Proxy Server IP address and port to match your Burp Suite proxy interface.
example 4
Proxy Settings Tab – Pointing Postman at your Burp Suite listener

The default proxy interface will be 127.0.0.1, port 8080 assuming you are running Burp Suite on the same machine as Postman. If you want to use a different port, you will need to specify it here and make sure it’s set to match the proxy interface in Burp.

Now that you are able to proxy traffic, there’s one more hurdle to consider. Today, SSL/TLS is used on most public APIs. This is a very good thing, but it means when Burp man-in-the-middles the Postman’s API requests and responses, you will get certificate errors unless your Burp Certificate Authority is trusted by your system. There are two options to fix this:

example 5
  1. You can turn off certificate validation in Postman. Under the General settings tab, there’s an SSL certification verification option. Setting it to Off will make Postman ignore any certificate issues, including the fact that your Burp Suite instance’s PortSwigger CA is untrusted.
  2. You can trust your Burp Suite CA to your system trust store. The specifics of how to do this are platform specific.
    PortSwigger’s documentation for it is here: https://support.portswigger.net/customer/portal/articles/1783075-Installing_Installing%20CA%20Certificate.html

Verify that it is working

Issue some requests in Postman. Check your HTTP History on the Proxy tab in Burp.

example 6
Proxy history in Burp Suite

Troubleshooting

  • Your request is stalling and timing out? Verify that Intercept is Off on the Proxy tab in Burp. Check that your proxy settings in Postman match the Proxy Interface in Burp.
  • Postman is getting responses but they aren’t showing in the Proxy History (etc) in Burp? Check the Settings in Postman to verify that Global Proxy Config is turned on. Make sure you haven’t activated a filter on the History in Burp that would filter out all of your requests. Also make sure your scope is set, if you’re not capturing out-of-scope traffic.

Next Steps

So this was two posts of pretty elementary setup type activity. Now that we have our basic tool-chain setup, we’re ready for some more advanced stuff. Part 3 will deal with variables in Postman, and how they can simplify your life. It will also dig into the scripting interface, and how to use it to simplify interactions with more common, modern approaches to Auth, such as Bearer tokens.

Join the Professionally Evil newsletter

Sign Up

Related Resources