Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to use Postman to better conduct API penetration testing. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

In this day and age, Web and mobile applications are usually supported by RESTful network services. Public and private API are very common on the Internet, and testing these API is not easy, but there are some tools that can help you. Although tools are no substitute for skills, even the most skilled carpenters can drive nails more effectively with hammers than with shoes.

Postman is one such tool that has been popular among developers for many years. Before we get to the topic of how to set it, let's take a quick look at what the tool is and what it can do. Postman is a commercial desktop application that can be used with Windows, Mac OS, and Linux. Most of its features are free, as well as paid features, such as collaboration and documentation. These features are more meaningful to developers than penetration testers. It is used to manage the set of HTTP requests that test various API calls. And the environment that contains variables. It doesn't replace your proxy (e. G. Burp,ZAP,Mitmproxy, etc.), but it actually makes up for the lack of functionality in the browser and client application layers. The main alternatives to this tool are open source tools Insomnia and advanced REST clients, commercial products SoapUI, or custom tools based on Swagger/Swagger UI or curl.

Set up Postman

Postman, an installer for Windows and MacOS, and a tar package for Linux can be found on its official website (https://www.getpostman.com,). It can also be found in Ubuntu's Snap for Ubuntu (HTTPs://snapcraft.io/postman) and other community-maintained repos, such as Arch Linux's AUR. The first step in setting it up is, of course, the program installation.

The first time you start Postman, you will see a screen that prompts you to create an account, sign up for Google, or log in with your existing credentials. However, Postman does not need an account to perform subsequent use.

Login accounts are used for collaboration / synchronization / etc.; these are paid functions. As I mentioned earlier, these features are great for developers, but for you, they may not care. In fact, if you usually need to keep your client's mechanical energy secret, as we did at Secure Ideas, then you may explicitly not want to synchronize your project to another third-party server.

If you look down at the bottom of the window, you will see some light gray text that says skip login and take me directly to the application interface. Click on the gray link and you will move to the next screen-a dialog box that prompts you to create something.

There are a few parts you won't use here, so let's take a look at the three features you really care about:

Set. Collection-A generic container that you can populate with requests. It can also be used as a top-level object for some configuration choices, such as authentication rules (Authentication rules), which we will explain in more detail later.

Request (Request)-this is the most important function. These are the HTTP requests you will build, using any method you want to use, HTTP Body, etc. These must always be in one set. Hezhong.

Environment (Environment)-here you can save where you want to control and issue cross-requests or even cross-sets. Match the variables used.

Basic knowledge of using Postman

It is time to create our first Postman set. Merge to issue a HTTP request.

The New button in the upper left corner is usually used to create sets. Agree with the request. Let's first create a set. Close. It's kind of like a separate application. You will use it to group related requests.

Set. The combination can also be used as a top-level item with authentication instructions that inherit a single request. Now, just give it a name and click the create button. Here, my name is "Test set. Close".

By default, you have opened an unnamed request tab. Let's take a look at this part of UI.

Active Tab

The name of this request. These are just descriptive names that you can write or not.

HTTP method. This drop-down control allows you to change the method of this request.

The requested URL. This is the complete path, just like in the address bar of your browser.

A tabbed interface for setting various properties of the request, including parameters, HTTP headers, HTTP bodies, and so on.

Send button. This is actually submitting the request to the specified URL.

Save button. The first time you click this option, you need to specify your set. Because the request must belong to a set. Close.

I set a sample target on HTTP://localhost:4000, so I will fill in this request and save it to one of my sets. Cooperation is the beginning. I will make a POST request to HTTP://localhost:4000/legacy/auth with no parameters (this is a test API. Anyone can be authenticated. When I click the save button, I will name the request and select a set for it. As shown in the following figure:

Then click Save to Test Suite. Close (according to your set. ) button to save my request. Now, clicking the Send button will make the request. Then I will see the response populated in the lower pane of the window, as shown in the following figure:

The tab interface contains Body, Cookies, Headers and test results. We haven't written any tests yet, but notice the cookie headers returned by the response marked in the figure.

The HTTP Body of the actual response is in the larger text pane.

We have a readable print method or options for the original response body, as well as different types of drop-down lists (I believe this is a pre-populated response header content-type). There is also a custom wrapper button in case you have other special operations.

The metrics of response include HTTP status code, response time, and response size.

A side note on Cookies

Now, if we reissue the request using Postman, we will notice an important thing: the cookie that was previously set in the response will be automatically included. It mimics what browsers usually do for you. As you would expect from the browser, any request made within the scope of this cookie, Postman will automatically include the cookie.

What do you do if you want to remove a cookie? There's nothing to it. Under the send button on Postman, there is a button similar to a link that says Cookies. Clicking this button will open a dialog box where you can delete or edit any cookies you need.

This is the API based on cookie. But let's face it: today's common API uses bearer tokens (Bearer Token), which is more common than Cookies.

Why set up proxies?

By using Postman, we can use it as an excellent tool to make requests from scratch and manage them. Through the Burp proxy Postman traffic, we can get these benefits: we can combine with Burp's intruder function for fuzzy testing, we can also use Burp's passive scanner to detect prominent security issues, we can also take advantage of Burp's extensions, which we will see in later chapters of this series of articles. And we can use Burp's Repeater to tamper with the request. You might say, we can also tamper with it in Postman. But what I want to say is that there are two important reasons for using Repeater: 1) Postman is designed to make correct and valid requests. In some cases, it attempts to correct incorrect syntax. When testing security issues, we may not want it to correct our tampering errors. 2) by using Repeater, we keep the clean state of requests in Postman and the separation between requests that have been tampered with in Repeater.

Set up Burp Suite

The actual introduction to Burp is beyond the scope of this article. If you are reading this article, chances are you are already familiar with it

Now, start Burp and check the Options tab under Proxy. The top part is the proxy listener (Proxy Listeners), and you should see a listener on 127.0.0.1 and port 8080. It must run all the time (pay attention to the check box). If it is not running by default, it usually means that the port is not available, and you need to change the listener (and Postman) to a different listener port. As long as the port on which Burp is listening is the same as the address and port of the proxy you set in Postman, then your setting should be fine.

Also check the Intercept tab under Proxy and verify that Intercept is closed.

Configure the Burp agent in Postman

Postman is agent-aware, which means we point it to our man-in-the-middle agent, Burp Suite. We will open the settings dialog box by clicking the wrench icon (1) in the upper right corner, and then click the settings option (2) on the drop-down menu. This opens a larger settings dialog with labels for different categories at the top. Locate the proxies tab and click to set it.

Open the Postman Settings panel

There are three things you can do on this tab:

Turn on the global proxy configuration switch (Global Proxy Configuration)

Turn off the use system Agent (Use System Proxy) switch

Set the proxy server IP address and port to the same as you set in the Burp Suite proxy

The default proxy interface is 127.0.0.1 and the port is 8080, which assumes that your Postman and your Burp Suite are running on the same machine. If you want to use a different port, you need to specify it here and make sure it is set to the same as the proxy interface in Burp.

Now that you can delegate traffic, there is one more problem to consider. Today, most public API uses SSL/TLS. This is a very good thing, but it also means that when Burp acts as a proxy broker in dealing with Postman's API requests and responses, you will encounter certificate errors unless your system has trusted Burp's certification authority. There are two ways to solve this problem:

You can turn off certificate verification in Postman. There is an SSL authentication verification option under the General settings tab. Setting to Off will cause Postman to ignore any certificate issues, including Burp Suite's PortSwigger CA.

You can set your Burp Suite CA to the system trust store. The specific setup details have something to do with the platform.

Verify that the agent is working properly

Make some requests with Postman. Check your HTTP history on the Proxy tab of Burp.

Agent history in Burp Suite

Troubleshooting

Is there a problem of delay and timeout in your request? Check to see if Intercept is turned off on the agents tab in Burp. Check that the proxy settings in Postman match the proxy interfaces in Burp.

Postman received a response, but the response is not shown in Burp's agent history (etc.)? Open the Settings interface of Postman and check if Global proxy configuration is turned on. Make sure you don't activate the Burp history filter to filter out all your requests. If traffic outside the filter range is not captured, the simulation also ensures that the range (scope) is set in the Burp.

Now we have made the basic tool chain settings.

Set. Combined variable

Variables in Postman can be used for almost any field in a request. The syntax is to use two layers of curly braces on both sides of them. There are several places where I can use variables to define them. If they are static, maybe I will set them to set. Combined variable. For example, I have been using http://localhost:4000 as my test host. If I change the port of the test API from 4000 to 4001, I don't want to edit each requested URL one by one. Next I'll show you how we can move it to a set. In the combined variable. First, open the set in the menu sidebar. Edit the set in the close list. Close the dialog box. I can click... Button or right-click the set. Match the name. For both operations, we will get the same context menu and select Edit.

This will open an edit set. Close the dialog box. The default view includes sets. A text box with the name and description of the combination, but there is also a line of tabs between the two fields.

One of the tags is called variable (Variables). This is what we want, and clicking this tab will open another dialog box for editing variables.

Postman set. Combined variable editing interface

It has a table that contains the variable name, initial value column, and current value column of a variable. The difference between the two value columns is related to the synchronization of Postman's payment function. The important point here is that you will enter the initial value and then the tab goes to the current value field. This will automatically populate the current initial value into the current value field, and it will look like the figure. Now I have a collection called API_host. Covariant, whose value is http://localhost:4000. You need to click the update button after you have finished editing the variable.

Now is the time to modify my request and reference this variable instead of using a hard-coded hostname and port.

Request in Postman to change URL to point to a variable

I simply replaced the corresponding part of each URL with a placeholder: {{API_host}}. Hover over the placeholder to expand this variable and display the value and range of the variable. Here are some color codes that can also help us. When the variable is valid, the text turns orange, but if I enter an invalid variable name, the text turns red.

I still need to update each request to use a variable. But in the future, if I change the port, or if I switch to HTTPS, or if I deploy my test API to a completely different host, then I can go back to the set. Combine the variable and update the value of the variable, and all my requests will change accordingly.

Now, set. Co-variables are fine for relatively static fields and fields that don't change very often, but what if I test multiple environments and deployments, or even multiple tenants, in a multi-tenant solution? I may use the same set of requests. Yes, but use a different set of variables. Close. Then in this case, the environment variable can deal with this problem.

Environment variable (Environment Variables)

You may have noticed the interface in the upper right corner of the window. Let's open it and take a look:

Interface of environment variables in Postman

Environment Selector drop-down menu. You can choose an environment.

Quick View button, you can click to see what is set in your environment.

Manage environment button, this is the place to actually edit the environment.

First, we need to click the manage Environment button. This opens a large but blank dialog box with an Add button at the bottom. Click the add button.

You will see another dialog box. This one looks almost set. The combination variable dialog box is the same, except that it has a name.

Here, I named mine LocalTest.

I have also added a number of other variables, one of which is called bearer_token with a value of foo. The other is a user_ id value of 1.

Once you have finished editing, we click the add button near the bottom of the dialog box and close the manage Environment dialog box. Before I can use this variable in this environment, there is one last important and often forgotten step: we need to select the environment from the environment selector drop-down menu.

Now these additional variables can be accessed like the API_host variable above: {{bearer_token}} and {{user_id}}

Routing parameter

It is common to use routing parameters in modern API. These are the values provided as part of the URL main path. For example, consider the following scenario, http://localhost:4000/user/42/preferences

The number 42 in such URL is actually a parameter, most likely the user ID in this example. When a server-side application routes an incoming request, the server extracts the value and makes it available for final processing of the request and a function that constructs the response at any time. This is a routing parameter. This is also relatively simple to edit parameters or to use in Postman. The syntax is to put the parameter directly into the URL in the form of a colon (:) followed by the parameter name. For this sample request in Postman, I enter it as {{API_host}} / user/:userId/preferences. Then, on the requested parameters (Params) tab, I can see that it is listed and the specific value is set. In the following figure, I set it to the user_id variable specified in the previous environment variable.

I can also write my variables directly into URL, but in my opinion, this way is cleaner.

Bearer token (Bearer Tokens)

Imagine a scenario where you make some kind of authorization request that responds with a bearer token, and then you need to use that token in all other requests. The manual way to do this might be to make an authentication request and then copy and paste the token from the response to another environment variable. All other requests can use this environment variable.

This can also make requests normally, which can be painful if you have a short-term token. There is a more elegant solution to this problem. Consider the following response:

We have made a request and received a JSON response with a token. Now, I want to update my environment variables with the new bearer token in an automated way. On the request interface, there are several tags that can do this. The one on the far right is called a test. This is mainly used to automatically check the response to determine if the API fails, just like a unit test. But we can achieve our goal through some JavaScript statements.

I add the script above, click Save, and then run my request again. Everything seems to be exactly the same as the first time. But if I use the Quick Look button to view the environment variables.

We can see that the current value has been updated automatically. This is the first step-- I now store the value in a place where I can easily reference it, but it doesn't put the Bearer token token in my request. I have two ways. The first method is that if we open the requested Authorization tab, we can set a Bearer token from the type drop-down list and point it to my variable.

This approach is not bad, but I need to make the same settings on each request. But the default authorization type for each new request is inherited parent authentication (Inherit auth from parent). In this case, the parent class is a set. Close. Therefore, if I switch the request back to the default type, then I can enter the edit set. Edit Collection the settings (the same as I entered the context menu of the Collection variable), and then go to the Authorization tab of Collection.

This feature shows almost the same interface as the Authorization interface in the request, and I can set authentication to the information in the same way. The difference now is that it is in the collection. Managed by Hezhong. By default, every new request I create will contain the bearer token unless I deliberately change the type of the request. For example, my authentication request may not require bearer token, so I need to set the type to No Auth on the Authorization tab of the request.

Occasionally, I come across applications that need to extract values from the XML or HTML body contained in the response. In this case, the built-in xml2Json function helps to parse the response content.

Use xml2Json to integrate HTML principals into JSON objects

Another feature to note is the Pre-request Script tab, which uses the same basic scripting interface. As you might expect, it executes before the request is sent. Some of my colleagues use this feature to set bearer token tokens, which is a completely effective method, but not what I usually use. This method can also be helpful when you just need to do it all at once, although I don't usually see it.

Set up Jython

Some of these extensions require the Python environment to be set up in Burp Suite, while Burp Suite does not configure Python environment information by default. If you have already configured it, you can continue with the following. If it is not configured, you can open Extender-Options and set the location of the Jython's separate JAR. If you need this download jar package, you can find it on jython.org.

Once the path is set, navigate to the BApp Store tab and start downloading the extension we're going to use. The two plug-ins I want to highlight are JSON Web Token Attacker and Autorize.

Now let's look at these two plug-ins in more detail.

JSON Web Token Attacker

There are already many ways to deal with authentication and authorization. JWT is probably the most commonly used method on modern API. If you check Bearer token in the following figure, you will notice several obvious signs of the JWT we are using: three fragments, separated by colon characters. The header and declaration part of the Base64 code, followed by an encrypted signature.

This token can be easily decoded in Burp suite's built-in decoder. Simply select a token and Base64 can decode the entire text. After decoding the text in the figure above, it is as follows:

{"alg": "HS256", "typ": "JWT"}. {"userid": 1, "tokenid": "fac15939-de30-481d-9d13-6ae89ecd7370", "iat": 1552444637, "exp": 155244823N30.

Although Burp's Decoder can decode the text in this way with minimal damage, I want to modify and re-encode it. Doing so will produce the following results:

EyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9LnsidXNlcmlkIjoxLCJ0b2tlbmlkIjoiZmFjMTU5MzktZGUzMC00ODFkLTlkMTMtNmFlODllY2Q3MzcwIiwiaWF0IjoxNTUyNDQ0NjM3LCJleHAiOjE1NTI0NDgyM04zMC7colISpedlNHItBvijbS0TmYWzzIFAAOmykTIWurMtDzVJ

This is similar to the original value, but absolutely different. This is because JWT is not a single base64-encoded string. The header and declaration parts are encoded separately, removing any padding information (represented by one or two equals signs).

There are some flaws in the JWT implementation, although most of them are rare. Exploitation of these defects includes tampering with JWT and re-coding. Although this can be done manually, JSON Web Token Attacker makes it easier to do so. We just need to copy the value from the request and switch to the JOSEPH tab in the Burp added by the plug-in. Next, open the Manuel subtab and paste the value into the input box. Then click the load button.

A drop-down box interface for attack selection is then displayed. There are two kinds of attacks: key obfuscation (Key Confusion) and signature exclusion (Signature Exclusion). Although an in-depth study of these attacks is beyond the scope of this article, I will give a brief summary that either of these two attacks will change the algal value of the header to a different algorithm; either switch it to the value of None (meaning no signature is required) or switch it from asymmetric encryption to symmetric encryption so that we can generate a valid signature with the public key. The security impact of either way is that encrypted signatures are usually the only way to ensure token integrity. If the attacker is able to crack the signature, the token can be modified to have any declaration that the attacker wants. In this example, this may mean that the attacker will change the session of user ID to obtain another account and use that account.

Let's take a look at the steps of the "signature exclusion" attack and gradually complete the basic manual attack:

Load input

Select signature exclusion

Load

Select a payload. These are variants of None.

Update

Gets the generated value and uses it for Repeater. If you start with a valid JWT as the start of the attack and the tampered version is accepted, then your attack is successful. After that, you can continue to tamper with the declaration part.

The actual use of key confusion is almost the same as signature exclusion, except that you need to provide the public key and convert it. The usual practice is that the signature algorithm chooses RS256, and the public key can be used to verify the signature.

Another thing you may have noticed is that the agent history in Burp now has a highlighted function and a new context menu.

This is a plug-in for semi-automatic attacks. I personally don't like using this plugin in this way, in part because I find it sometimes messy and generate malformed requests, and partly because I like to strictly control the traffic I send. In addition, a rare situation for systems that implement JWT invalidation blacklists is that malformed tokens blacklist sessions.

However, even the manual attack mode greatly simplifies the process of generating a modified JWT. This makes this approach often a useful tool for API testing. I have found that the implementations that produce these exploits do not seem to be common, but given their severity, these vulnerabilities should always be tested.

Automation (Autorize)

Various authorization issues may arise in API. Unless the API is fully public, you at least have authenticated and unauthenticated access. If there is a concept of resources or data owned by a particular user, it makes sense to verify that an authenticated user cannot access any resources they do not own. Some API also have multiple vertical levels of access, especially in the context of an organized concept. One user may have access to more data or functions than another. Again, it is up to the tester to confirm that this permission configuration is enforced. Finally, in multi-tenant systems (for example, each client organization has its own independent space), data or access leakage between tenants is one of the biggest security issues.

In all of these cases, the common test strategy is to map resources and functions to users with the correct permissions. Then we re-issue the same request with different access tokens or sessions and compare our access results. This validation process can be time-consuming when the permission model has any real complexity. Automation can significantly improve the efficiency of testing. Let's start by navigating to the Autorize tab in Burp so that we can complete the basic settings.

When switching authenticated context, the header we want to replace has a large text box. This can include Cookie and any other request headers, which are set as in a normal request.

For cookies, you can automatically populate the text box by clicking the button "get cookie from the last request".

Highlighted button "Autorize is..." Used to toggle the plug-in on and off. When turned off, automation will do nothing. When started, incoming requests that hit proxy* will be replaced and reissued with the headers or cookie you provided, omitting these headers or cookie.

* the intercept filter tab at the bottom of the interface can be used to determine which requests are included.

Now that the Autorize is set, you can issue a new request through Postman and notice that the Autorize area on the left will be populated.

My example API happens to have the same response, as you can see from the three numeric columns showing the response length (74 and 6, respectively). The first is a response to an unmodified request, the second is a request that replaces a token, and the third is an unauthenticated response. The remaining two columns are enforced with the same color as traffic lights. The yellow part of the figure represents an uncertain response, while the red and green parts are used to indicate whether the authorization is enforced or successful, respectively.

You can now use the unauthenticated request probe and Force request detector tabs at the bottom to adjust when the authentication takes effect. This allows you to create matching conditions based on your understanding of API behavior and greatly improves the result's interpretation of the response. For larger API, or for API that you expect to test multiple times, it's certainly worth it. However, for one-time tests, I usually do not tune this, but manually check for responses or length inconsistencies.

You can use the tab to the right of Autorize UI (similar to the typical request and response tab in Burp) to check for modified and unauthenticated requests and responses. This is critical to studying why there are differences between requests, what API does, and whether it is the right request for the server.

On how to use Postman to better conduct API penetration testing is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.