Portswigger Labs — CSRF

It’s been a while since the last update, with too many trivial matters affecting the progress. Without further ado, let’s dive into today’s topic: exploiting and bypassing CSRF vulnerabilities.

Lab: CSRF vulnerability with no defenses

This lab’s email change functionality is vulnerable to CSRF.

To solve the lab, craft some HTML that uses a CSRF attack to change the viewer’s email address and upload it to your exploit server.

You can log in to your own account using the following credentials: wiener:peter

After logging in, click on “update email” and capture the traffic.

Without CSRF token restrictions, generate a CSRF POC (Proof of Concept) directly and copy the HTML to the exploit server.

Simply deliver the exploit to the victim.

Lab: CSRF where token validation depends on request method

This lab’s email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

You can log in to your own account using the following credentials: wiener:peter

Capture the packet after updating the email.

After modifying the CSRF token, repeat the process:

It reminds invalid csrf token.

Changing the POST method to GET was successful.

Token verification is no longer in place. Similarly, copying the payload to the exploit server is sufficient.

Lab: CSRF where token validation depends on token being present

This lab’s email change functionality is vulnerable to CSRF.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

You can log in to your own account using the following credentials: wiener:peter

Similarly, inspect the captured packets.

The CSRF token is present.

After modifying the token, attempting to change the request method is unsuccessful. Try removing the token directly:

It worked.

Lab: CSRF where token is not tied to user session

This lab’s email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren’t integrated into the site’s session handling system.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

All the methods mentioned earlier will fail.

Click “update,” capture the packet, copy the CSRF token, and then drop it.

Open a new browser, update the email again, and replace the CSRF token from the previous step.

Successful modification.

Following the steps of the first lab, generate a CSRF PoC and replace the CSRF token with an unused one.

Lab: CSRF where token is tied to non-session cookie

This lab’s email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren’t fully integrated into the site’s session handling system.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

Here are two accounts provided. After logging in, send them to repeater.

It is found that by simultaneously replacing csrfKEY and csrf, the request can be completed normally.

There is no CSRF protection in the search field.

Therefore, leveraging the search parameter, inject your personal CSRF key into the browser:

Success.

The final exploitation strategy is to replace both your CSRF key and CSRF at the victim’s end. Inject the CSRF key through injection, and CSRF through the proof of concept (POC).

The injected code is as follows:

Combining with the POC, the exploitation is successful.

Lab: CSRF where token is duplicated in cookie

This lab’s email change functionality is vulnerable to CSRF. It attempts to use the insecure “double submit” CSRF prevention technique.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

Here, if the CSRF parameter exists in both the cookie and the body, modifying either one individually will result in an error. However, after experimentation, it was found that modifying both simultaneously allows for a successful request.

The following steps are similar to the previous ones.

First, inject the CSRF from the cookie into the victim’s browser using the search feature. Then, provide the victim with a matching CSRF through the POC:

Lab: CSRF where Referer validation depends on header being present

This lab’s email change functionality is vulnerable to CSRF. It attempts to block cross domain requests but has an insecure fallback.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

There is no CSRF token here, but there is a restriction on the referer. If the referer is modified, it will result in an unsuccessful request:

In other words, when using the previous POC to execute an attack, it fails due to inconsistent referer.

Trying to remove the referer:

Success.

Modify the POC:

Deliver the payload and finish it.