SourceCodester Lost and Found Information System sql injection

Vulnerability

In SourceCodester Lost and Found Information System version 1.0, the file /classes/Master.php contains an unknown function accessible via the f=delete_item parameter. This endpoint does not properly sanitize user-supplied input passed via the id POST parameter, leading to a classic SQL injection vulnerability. The code directly concatenates the user input into a SQL query without parameterization or escaping. The vulnerability is confirmed in the publicly available exploit proof-of-concept [1].

Exploitation

An attacker can exploit this vulnerability remotely without requiring any authentication or prior privileges. The attack is performed by sending a crafted POST request to /classes/Master.php?f=delete_item with a malicious id parameter containing SQL injection payloads. The exploit does not require any user interaction and can be executed over the network with a simple HTTP request. The provided proof-of-concept demonstrates the use of a time-based blind SQL injection payload (e.g., using AND GTID_SUB...) to extract information from the database [1].

Impact

Successful exploitation allows an attacker to execute arbitrary SQL commands on the backend database. This can lead to full disclosure of sensitive data stored in the database, such as user credentials, personal information, or lost-item records. The attacker may also be able to modify or delete data, potentially compromising the integrity and availability of the application. Since the application runs with the database server's privileges, the impact could extend to the underlying system depending on the database configuration [1].

Mitigation

As of the publication date of this CVE (May 11, 2023), no official patch has been released by SourceCodester. The vendor has not provided a fixed version. The recommended mitigation is to immediately disconnect the vulnerable system from untrusted networks or take it offline until a patch is available. For code-level remediation, developers should replace all dynamic SQL queries with parameterized prepared statements or use an ORM library that safely handles user input. Input validation and escaping alone are insufficient to fully prevent SQL injection [1].