|Affected Version(s)||3.5.0 and probably prior|
|Vendor Notification||13 June 2022|
|Advisory Publication||13 June 2022 [without technical details]|
|Public Disclosure||13 June 2022|
|Latest Modification||09 June 2022|
|Product Description||A free online ordering system for restaurants & takeaways based on Laravel PHP Framework.|
|Credits||Oswaldo Morales Rodríguez Security Researcher & Penetration Tester @wizlynx group|
|Severity: Medium||CVSS Score: 5.4||CWE-ID: CWE-79||Status: Open|
|CVSS Base Score|
|Attack Complexity||Low||Confidentiality Impact||Low|
|Privileges Required||Low||Integrity Impact||Low|
|User Interaction||Required||Availability Impact||None|
Two stored XSS were identified.
The first one can be crafted by a customer. Indeed, while creating a Reservation, the Name field of a customer can be injected with an XSS payload. This payload will be triggered whenever an administrator will edit the customer reservation.
The second XSS injection requires a more elevated access privilege. In this scenario, the name of a table can be injected with an XSS payload by a privileged user. Whenever this table is assigned to a customer reservation and the reservation is edited the XSS payload will be triggered The steps to reproduce are listed below:
First scenario: Customer name XSS
An external customer could craft a malicious reservation including an XSS Payload.
A customer can register itself and input a xss payload in its name as shown in the image below:
Because of the missing input validation, the user was registered with the given name as shown in the image below:
The newly created customer can make a reservation as shown in the screenshot below. NOTE: Due to a bug in the application, we will need to modify the HTML of the page by removing the "disabled" tag in order to proceed and register the reservation.
The screenshot below shows the element that needs to be deleted
As shown in the screenshot below the reservation was done successfully
Whenever this reservation is edited by an administrator, the XSS payload will be triggered as shown in the images below. First name payload:
Last name payload:
Finally, as shown in the image below, the payloads are not encoded in any form as shown in the html
Second scenario: Table name XSS
This scenario could lead to an internal attack since a manager could create a malicious table and alter a reservation. Once that is done the manager could trick an Admin (a higher privilege access level) into triggering the payload.
First. a table needs to be created.
Afterward the table shall be named with the xss payload:
Once the table is created the next step is to create a reservation with a registered user. The extension Reservation was used. Note: As we mentioned before, the modification of the HTML is needed to enable the Email Address field.
Once the reservation has been done. It is needed to change the table assigned for the one with the malicious payload as shown in the screenshot below:
Afterwards if one reviews the reservation of the customer the payload will be triggered.
As shown in the screenshot below the payload is not encoded