JMetesr—How to Load Test CSRF-Protected Web Sites

As shown in below Figure (click to enlarge), an X-CSRF-Token header is used in an HTTP request.  In this article, we will discuss how to load test CSRF-Protected web sites using JMeter.  To begin with, what is CSRF?

Figure 1.  X-CSRF-Token header shown in View Results Tree

Cross-Site Request Forgery (CSRF)

Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. Cross-Site Request Forgery (CSRF) attacks occur through a malicious website that sends the requests to the targeted application website if the user is already authenticated through a different website.

These attacks happen if the user logs in to the actual website and leaves the session open, and accesses the malicious website links and forms that try to form the dynamic URLs to the targeted application where the user has already logged in.

The best way to prevent CSRF attacks is to attach CSRF tokens to each request from the application users and bind them to the user session. This way, the applications can restrict the access to the user's secure information by confirming the request is coming from known user sessions.

View Results Tree

After script recording, the best way to debug correlation issues is to use View Results Tree component (a Listener).

The View Results Tree shows a tree of all sample responses, allowing you to view the response for any sample. In addition to showing the response, you can see the time it took to get this response, and some response codes.

Note that View Results Tree MUST NOT BE USED during load test as it consumes a lot of resources (memory and CPU). Use it only for either functional testing or during Test Plan debugging and Validation.

From Figure 1, we have found an X-CSRF-Token header used in Step 32.  This means that we need to search for CSRF token backwards in the Response Data of earlier Steps.

Correlation

From the end-user’s point of view, CSRF protection is transparent. On the protocol level, CSRF protection is an additional mandatory dynamic parameter, such as the:^[2]

• Cookie
• Header
• Request Parameter

When a real-life user surfs a CSRF-protected website with a web browser, the browser’s CSRF security token can be set (for example: this can be set with a JavaScript function). Now, here’s where JMeter’s “not being a browser” issue really becomes a limitation. As it’s not a browser, it can’t execute a client-side JavaScript and therefore can’t generate and record a proper CSRF token.

To resolve the challenges raised by CSRF sites, you’ll need to use a JMeter Correlation.  In this article, we will demonstrate the use of a JMeter PostProcessor Regular Expression Extractor to extract the CSRF token.

Figure 2.  Specification of  a PostProcessor Regular Expression Extractor 

Regular Expression Extractor

At Step 15 (see Figure 2), you need to add a new PostProcessor Regular Expression Extractor to extract the CSRF token.

Sample Response Data:

[

  {

   <snipped>

    "bimodelerURL": "/bimodeler",

    "csrftoken": "h3CYF2EDNYlfBPKM01grVQQMfUKE0lAvhwfRzHtxU1Mdigx6",

    "vaAdminPermission": true,

   <snipped>

   }

]

Regular Expression:

"csrftoken":"([^\"]+)


Then, you can use a text editor to open the jmx file and do a global replacement of

h3CYF2EDNYlfBPKM01grVQQMfUKE0lAvhwfRzHtxU1Mdigx6

with

${csrftoken}

For example, at Step 32, you should see something updated like below:

Figure 3.  Variable Substitution in HTTP Header

References

1. Oracle JET for Developers
2. How to Load Test CSRF-Protected Web Sites