Web API to test csrf token validation with JMeter

The cause of the incident is a recent batch of testing requirements to test the interface performance of the company's HR system. This is the list of interfaces that need to be tested:

All interface requests are successful based on login verification, otherwise the correct answer will not be obtained.

The first thing to think about is capturing requests on the browser. Open the Chrome browser, bring up the Developer toolbar, enter the address of the login module in the Address bar, visit the login page:

Enter your account and password to record the login process, then navigate to the Network page of the developer tool to locate the logged in transaction. Such as:

Note that the bottom right of form Data, which is the login post method submitted by the three parameters, we need to capture the _csrf of the dynamic token.

Through the online search and local experiments, the successful completion of the script debugging.

Here's the whole process:

Start the JMeter UI first, create a new thread group, and then add an HTTP request named Userlogin–open, which is intended to get the CSRF Token for the first time you open the login page.

Method uses get, and the actual login commit will be post; Here is not the actual login, do not care.

It is important to check this option by ticking "follow redirect", including the HTTP request created later.

Request Parameters section, fill in the user name and password. Since CSRF token cannot be acquired at this time, the login will not be successful, but the purpose is not to login, but to obtain the content of CSRF token.

When finished, create a "post processor-Regular expression extractor", which extracts the CSRF Token from the login page response message. Content such as:

Apply to option: Check applies to main sample only.

It is important to note that the "response field to check", the online guidance is "message header", but in my test, from the message header can not get the information of CSRF token, so to be set in the "main".

Reference name: can write casually;

Regular expression: the content that you want to extract, the format needs to be looked up from the reply message. Here you can refer to the notation of LoadRunner's Association (left margin, right margin, regular expression matching rules).

A friend who has no clue can be found in the response message from the "View results tree", such as:

Template: $1$, which represents the first value;

Default value: Random, default is empty.

Next, create an HTTP request, this time to implement a real login request.

Create a second HTTP request, named Userlogin–post, because the login method is POST, and is distinguished from the previous one:

This time we need to fill in the three parameters of the login submission, CSRF token needs to refer to the previous step from the "Regular expression extractor", the notation is: ${token}.

When we're done, we can theoretically run the login script, but don't worry, you'll need to add an HTTP cookie manager.

Let's look at the situation without the HTTP cookie manager:

Two CSRF tokens are inconsistent, stating that they are treated as two unrelated visits.

Look at the second HTTP request to submit the information, the contents of the CSRF token here is the same as the first reply message, that our previous efforts are correct, but why still not landed success?

Think about it a little bit to understand, the server side to determine whether two requests from the same client, more than one csrf Token, there are other, such as the session ID.

Let's go back to the browser's developer tools page to see:

There are obviously three parameters in the cookie that can be expected each time the request is submitted, these three parameters are dynamic values;

To maintain consistency throughout the session, we need to add an HTTP cookie manager to the JMeter script:

Add any items you don't need to set up in the future, and it's enough to keep the initial state.

To make sure that the HTTP cookie manager is in effect, you need to modify the jmeter.properties in the Jmeter\bin directory.

Find the option CookieManager.save.cookies, change the value to true, and delete the # number at the beginning of the sentence for the configuration to take effect.

After you complete the modification, you need to restart JMeter.

After rebooting, let's take a look at the results:

Compared to the previous execution results, the response data of Userlogin–post has changed, and the title of the display is "My Workbench", which is an important sign of the success of the login;

and two HTTP requests received the same CSRF token content, the login operation was perfect.

This is followed by requests to add other business APIs, which are easy to write because they are all get methods.

When finished, add aggregated reports and monitor the backend listener to live.

For example, let's take a look at the user's attendance record:

Take a look at the response message:

As expected, the API to access other features after logging in will also get the correct answer.

The scripting work is basically done.

Web API to test csrf token validation with JMeter