# PortSwigger Academy: CSRF Labs
This is a write-up for the PortSwigger Academy: CSRF Labs found [here](https://portswigger.net/web-security/csrf/lab-no-defenses). To learn more about exploiting CSRF vulnerabilities, visit the PortSwigger Academy Learning Path [here](https://portswigger.net/web-security/learning-paths/csrf/csrf-bypassing-samesite-restrictions-via-vulnerable-sibling-domains/csrf/bypassing-samesite-restrictions/bypassing-samesite-restrictions-via-vulnerable-sibling-domains).

## Solutions:
### [Lab: CSRF vulnerability with no defenses](https://portswigger.net/web-security/csrf/lab-no-defenses)

1. To start, open Burp Suite and launch the browser. Navigate to the challenge page and access the lab. Sign in using the given credentials, `wiener:peter` and proceed to the `My account` page. From here, provide a test email address for the account, like so:


View the web traffic in the Burp Suite Proxy:

The email for the account should be updated:

From this, we can see that:
* The email gets updated from a url: `https://<lab-id>.web-security-academy.net/my-account?id=<username>`
* The form on the `update-email` page is submitted with a single parameter, `email`.

2. Since the webpage has no defenses against CSRF, craft a payload, like so:


In the Lab Environment, click `Go to exploit server` to create your payload. Then make sure your payload has the following properties:
> 1. The form `action` attribute should be set to the url, where the email gets updated. The method should be `post`.
> 2. There should be one input tag inside the form, which submits an attacker email address, like `[e-mail]`. Since it does not need to be viewed, a `hidden` type should work
> 3. Create a script to automatically submit the payload in the victims browser once the page loads.

Once the payload has been created, click `Deliver exploit to victim`. Observe the `Access log` to see if your exploit has been accessed by the victim. Once it has, it it works, you will see a `lab solved` banner at the top:

**Tip**: These Burp Suite labs, which require exploit delivery, don't always indicate whether your exploit was successful immediately. They may even timeout without notifying you if the exploit was successful. Document your exploit somewhere seperate, and try submitting again another time. If the issue persists, contact Burp Suite Support by email: `support <at> portswigger <dot> com`

### [Lab: CSRF where token validation depends on request method](https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-request-method)

1. To start, open Burp Suite and launch the browser. Navigate to the challenge page and access the lab. Sign in using the given credentials, `wiener:peter` and proceed to the `My account` page. From here, provide a test email address for the account, like so:


View the web traffic in the Burp Suite Proxy:

This time, observe that part of the form submission is a `csrf` token. Since this is randomly generated by the web server, and not stored by the browser, this value cannot easily be guessed or retrieved.

From the challenge description, we know that this defense only applies to `certain types of requests`.

2. Test to see if the form data can be submitted using a `GET`request, using a url like so: `https://<lab-id>.web-security-academy.net/my-account/change-email?email=[e-mail]`

3. If the test is successful, craft a payload like so:

Once the payload has been created, click `Deliver exploit to victim`. Observe the `Access log` to see if your exploit has been accessed by the victim. Once it has, it it works, you will see a `lab solved` banner at the top:

### [Lab: CSRF where token validation depends on token being present](https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-token-being-present)

1. To start, open Burp Suite and launch the browser. Navigate to the challenge page and access the lab. Sign in using the given credentials, `wiener:peter` and proceed to the `My account` page. From here, provide a test email address for the account, like so:

View the web traffic in the Burp Suite Proxy:

This time, observe that part of the form submission is a `csrf token`. Since this is randomly generated by the web server, and not stored by the browser, this value cannot easily be guessed or retrieved.

From the challenge description, we know that this defense is still vulnerable as the test `depends on token being present`.

2. Send the web request to the `Repeater`. Remove the `csrf` parameter and update the email address, like so:

Observe whether the redirect was successful. If so, go to the browser and navigate to the `My account` page. Observe the updated email address, `[e-mail]`:

3. Since removing the parameter allows the request to be made, craft a payload, like so:

In the Lab Environment, click `Go to exploit server` to create your payload. Then make sure your payload has the following properties:
> 1. The form `action` attribute should be set to the url, where the email gets updated. The method should be `post`.
> 2. There should be one input tag inside the form, which submits an attacker email address, like `[e-mail]`. Since it does not need to be viewed, a `hidden` type should work
> 3. Create a script to automatically submit the payload in the victims browser once the page loads.

Once the payload has been created, click `Deliver exploit to victim`. Observe the `Access log` to see if your exploit has been accessed by the victim. Once it has, it it works, you will see a `lab solved` banner at the top: