FirstBlood-#1184 — CSRF bypass on edit-dr.php
This issue was discovered on FirstBlood v3

On 2022-12-08, 0xblackbird Level 5 reported:

Summary:

Hi!

I found out that there's no CSRF protection when you remove the csrf body parameter from the request. This meant it is fairly easy to exploit it and edit doctors' information using a simple POST form.

Possible cause:

I suspect that the developers only coded the part to validate CSRF tokens when they are present.

Impact:

I'm able to perform unwanted actions on other authenticated user's behalf (as long as they visit my link).

Steps to reproduce:

1) Copy the following PoC code and save it in a HTML file.

<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('', '', '/')</script><form action="https://2c724b2992e1-0xblackbird.a.firstbloodhackers.com/drpanel/drapi/edit-dr.php" method="POST"><input type="hidden" name="drid" value="3" /<input type="hidden" name="name" value="xyz" /><input type="hidden" name="bio" value="test" /><input type="hidden" name="bookable" value="1" /><input type="submit" value="Submit request" /></form></body></html>

2) Open it in a browser and submit the form (make sure you're authenticated)

3) You should see that the response isn't blank + it says that the changes were made successfully:

4) Going to /doctors.php will reveal the changes that have actually been made.

Mitigation

I recommend checking if the csrf parameter was sent along in the request or not before validating it.

Have a great day!

Kind regards, 0xblackbird

P4 Low

Endpoint: /drpanel/drapi/edit-dr.php

Parameter: csrf

Payload: /

FirstBlood ID: 58
Vulnerability Type: Cross Site Request Forgery

There is a CSRF vulnerability on /drpanel/edit-dr.php via a GET request and lack of token validation. It was intended that a POST request does not work due to no cookies sent on the request (because of SameSite), but to an over sight this cookie was overwritten rendering it useless.