Bank Locker Management System - SQL Injection

Bank Locker Management System – SQL Injection Vulnerability Analysis

Security vulnerabilities in web applications are a persistent threat, especially in systems handling sensitive data like financial or personal information. The Bank Locker Management System, a PHP-based application developed by phpgurukul.com, exemplifies how poor input validation can lead to severe security breaches. This article explores a critical SQL Injection vulnerability discovered in the system's authentication mechanism, detailing its exploitation, impact, and mitigation strategies.

Overview of the Vulnerability

The Bank Locker Management System is designed to manage customer lockers in a banking environment using PHP and MySQL. While the application offers a structured interface for banking staff, it suffers from a fundamental flaw in its login process. The vulnerability stems from improper handling of user input, allowing attackers to manipulate SQL queries through malicious payloads.

Specifically, the login form—accessible via http://blms.local/banker/—accepts user credentials without sanitizing input. This oversight enables attackers to inject SQL code directly into the authentication query, bypassing security checks entirely.

Proof of Concept (PoC)

Consider the following payload used in the login form:

admin' or '1'='1-- -

This payload exploits the SQL injection flaw by manipulating the query logic. Let’s break it down:

• admin' — This part is a literal string, intended to mimic the username.
• or '1'='1 — This is a logical condition that always evaluates to true. Since '1'='1 is a constant truth, the entire condition becomes valid regardless of the actual user data.
• -- - — This is a comment delimiter in SQL, effectively nullifying any remaining query parts after the injection.

When submitted, the resulting SQL query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1' -- - AND password = '...'

Because '1'='1 is always true, the query returns all records matching the condition, including administrative accounts—effectively granting access without needing a valid password.

Impact and Risks

SQL Injection in a banking system like this poses significant risks:

• Unauthorized Access: Attackers can gain full administrative privileges without credentials.
• Data Exposure: Sensitive customer data, locker details, and financial records could be extracted.
• System Manipulation: Malicious users could delete records, alter locker assignments, or even inject backdoors.
• Reputation Damage: A breach in a financial system can erode trust and lead to regulatory penalties.

Given that the application is hosted on WAMP server (Windows 10), it's likely deployed in a local or development environment. However, if deployed in production, the risk escalates dramatically—especially if exposed to the internet without proper firewall or WAF (Web Application Firewall) protection.

Technical Root Cause

The vulnerability arises from the use of concatenated SQL queries without parameterized inputs. For example, a typical flawed login query might look like:

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password';";

This approach is dangerously insecure because it directly embeds user input into the SQL statement. Any input containing single quotes or logical operators can disrupt the intended logic.

Secure Fix: Parameterized Queries

The proper solution is to use prepared statements with parameterized queries. This ensures that user input is treated as data, not executable code. Here’s a corrected implementation using PHP’s PDO extension:

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);
$result = $stmt->fetch();

Why this works: The ? placeholders are bound to variables, preventing SQL injection. Even if an attacker enters admin' or '1'='1-- -, the system treats it as a literal string, not as SQL code. The query remains safe and logically intact.

Additional Security Best Practices

Beyond fixing the SQL injection, the application should adopt a holistic security approach:

• Input Validation: Sanitize all user inputs using whitelisting or regex patterns.
• Rate Limiting: Prevent brute-force attacks by limiting login attempts.
• Session Management: Use secure session tokens and enforce session timeouts.
• Logging and Monitoring: Track login attempts and detect suspicious behavior.
• Regular Security Audits: Conduct penetration testing and code reviews.

Vendor Responsibility and Public Awareness

While the application is hosted on phpgurukul.com, a platform that provides educational PHP projects, the presence of such vulnerabilities underscores the need for developers to prioritize security from the outset. Developers should never assume that "educational" systems are exempt from real-world risks.

Public disclosure of vulnerabilities like this helps raise awareness. It encourages developers to learn from mistakes and reinforces the principle that security must be integrated into every stage of development—not added as an afterthought.

Conclusion

The Bank Locker Management System serves as a cautionary tale: even simple applications can harbor critical vulnerabilities if security practices are ignored. SQL Injection remains one of the most prevalent threats in web applications, especially in legacy or poorly designed systems. By adopting secure coding practices—such as parameterized queries, input validation, and regular audits—developers can prevent such exploits.

For anyone deploying or using this system, immediate action is required: update the code, implement proper SQL handling, and conduct a full security assessment. Security is not optional—it’s essential.