FirstBlood-#184 — Authorisation vulnerabilities with cookies
This issue was discovered on FirstBlood v1

On 2021-05-11, xnl-h4ck3r Level 4 reported:

Summary

The cookie doctorAuthed is created when you try to register, but even if you are unsuccessful. It is also a fixed Base64 encoded field of {"doctorAuth":authed} that never changes for any user or session.

The cookie drps is created when a user logs in, however it is also created for a user when they register even if they have not continued to login after registering.

Steps to Reproduce

  1. Go to /register

  2. Ensure no cookies currently exist.

  3. Enter a random username and invite code and click SECURE REGISTER

  4. Open dev tools (Application tab) and observe the cookie doctorAuthed has been created with a value of eyJkb2N0b3JBdXRoIjphdXRoZWR9.

  5. This cookie is required to perform some authorised actions (e.g. with this cookie, the user is able to update their email on book apppointment - see Bug #81)

  6. G oback to /register

  7. Enter a valid username and invite code and click SECURE REGISTER

  8. Open dev tools (Application tab) and observe the cookie drps has been created, but the site says you need to continue to login.

  9. Visit /drpanel/index.php and observe that although you haven't logged in, you can now access the management screen.

Imapct

Improper authorisation controls all attackers to perform actions on the site that they should not be authorised to perform.

P2 High

Endpoint: /register.php

Parameter: n/a

Payload: n/a

FirstBlood ID: 7
Vulnerability Type: Application/Business Logic

The endpoint MA.php (to modify an appointment) only allows for certain values to be modified, however due to some application logic error, if the user has tried to signup as a doctor and has the cookie "doctorAuthed" set, then it allows them to modify the email address for any appointment.