| Vendor |
|
| Product | TastyIgniter |
| Affected Version(s) | 3.5.0 and probably prior |
| Tested Version(s) | 3.5.0 |
| Vendor Notification | 13 June 2022 |
| Advisory Publication | 13 June 2022 [without technical details] |
| Vendor Fix | N/A |
| Public Disclosure | 13 June 2022 |
| Latest Modification | 09 June 2022 |
| CVE Identifier | CVE-2022-38256 |
| 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 |
| Stored XSS | |||
| Severity: Medium | CVSS Score: 5.4 | CWE-ID: CWE-79 | Status: Open |
| Vulnerability Description | |||
| TastyIgniter is affected by Stored Cross-Site Scripting (XSS) vulnerability affecting version 3.5.0. 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. | |||
| CVSS Base Score | |||
| Attack Vector | Network | Scope | Changed |
| 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
