Security Research & Advisories

Stored Cross-Site Scripting (XSS) Vulnerability in TastyIgniter v3.5.0

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

Vulnerability Details

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

PoC

Demonstration

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

Top