Vulnerability: SQL injection. Because user input is pasted straight into the SQL text, an attacker can type SQL syntax that changes the meaning of the query.
Vulnerable code
query = "SELECT * FROM users WHERE username = '" + username +
"' AND password = '" + password + "'";Exploit (authentication bypass). Username: admin' --, password: anything. The query becomes:
SELECT * FROM users WHERE username = 'admin' --' AND password = 'x'-- starts a comment, so the password check disappears and the attacker logs in as admin. Entering ' OR '1'='1 in both fields makes the WHERE clause always true and returns every user, usually logging in as the first (often the admin). Worse inputs can read other tables (UNION SELECT) or drop data.
Prevention
- Parameterized queries / prepared statements — the main fix; input is sent as data, never as SQL:
PreparedStatement ps = conn.prepareStatement(
"SELECT id, password_hash FROM users WHERE username = ?");
ps.setString(1, username);- Use an ORM or stored procedures that bind parameters.
- Validate input (allow-lists, length limits) and escape output.
- Least privilege: the app’s DB account cannot DROP tables or read unrelated data.
- Show generic error messages; use a WAF; rate-limit and lock out repeated failed logins.
Storing passwords securely
- Never store plain text or reversible encryption, and avoid fast hashes like MD5/SHA-1.
- Use a slow, salted password hash:
- bcrypt, Argon2 or PBKDF2
- , with a unique random salt per user and a high cost factor.
- At login, fetch the hash by username and compare with the hash function (e.g. bcrypt.compare) — not inside the SQL.
- Add MFA, use HTTPS for the login form, and enforce strong passwords.
— rhs