Prevención de la inyección SQL
Comprenda cómo funciona la inyección SQL e implemente defensas sólidas mediante consultas parametrizadas y prepared statements.
Prevención de la inyección SQL es una lección gratuita de Secure Coding & OWASP Top 10 for Backend en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Secure Coding & OWASP Top 10 for Backend, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Secure Coding & OWASP Top 10 for Backend incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
What is SQL Injection?
Imagine you're talking to a database using a special language called SQL. Sometimes, bad actors can trick your application into sending unexpected SQL commands to the database.
This trick is called SQL Injection (SQLi). It happens when user input is treated as part of the SQL command itself, rather than just data.
SQLi can lead to:
- Data theft or modification
- Bypassing login screens
- Gaining control over the database server
How SQLi Works: A Login Example
Let's say a login form takes your username and password. The application might build a SQL query like this to check if you exist:
SELECT * FROM users WHERE username = 'your_username' AND password = 'your_password';
What if 'your_username' isn't just a name, but also a piece of SQL code?
The Vulnerable Code
A common mistake is building SQL queries by directly combining (concatenating) user input with the query string. Here's a simplified example in Java:
public class Main {
public static void main(String[] args) {
String username = "admin"; // User input
String password = "pass123"; // User input
// DANGEROUS: String concatenation
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';";
System.out.println("Executing query:\n" + query);
// In a real app, this query would go to the database.
}
}Crafting the Malicious Input
Now, imagine a malicious user enters this as their username:
admin' OR '1'='1
And any text for the password. When combined with the vulnerable query, it becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'any_password';
The OR '1'='1' part makes the condition always true, effectively bypassing the password check and logging the attacker in!
Introducing Prepared Statements
The best defense against SQL Injection is using Prepared Statements (also known as Parameterized Queries).
They separate the SQL logic from the user-provided data. Instead of directly inserting input, you use placeholders (like ?) in your query.
The database then understands that anything provided for these placeholders is pure data, not part of the command.
Prepared Statements in Action
Here's how you'd use a prepared statement to safely query for a user by their ID. Notice the ? placeholder.
public class Main {
public static void main(String[] args) {
int userId = 123; // User input
// Secure: Using a placeholder for the value
String sql = "SELECT name, email FROM users WHERE id = ?;";
// In a real application, you'd 'prepare' this SQL
// and then 'set' the parameter value (userId) separately.
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (id): " + userId);
// The database treats 'userId' as a value, not SQL code.
}
}How Parameters Prevent SQLi
When you use a prepared statement:
- Separation of concerns: The SQL query structure is sent to the database first.
- Data vs. Code: The database 'pre-compiles' the query. Then, when you provide values for the placeholders, it treats them strictly as data.
- Automatic Escaping: The database automatically handles any special characters in your input, preventing them from being interpreted as SQL commands.
This ensures that malicious input like ' OR '1'='1 cannot alter the query's intent.
Securing the Login Example
Let's fix our vulnerable login example using prepared statements. Now, even if a user tries to inject SQL, it will be treated as part of their username/password, not as a command.
public class Main {
public static void main(String[] args) {
String username = "admin' OR '1'='1"; // Malicious input
String password = "any_password"; // Malicious input
// SECURE: Using prepared statement with placeholders
String sql = "SELECT * FROM users WHERE username = ? AND password = ?;";
// Simulating how parameters are set (conceptual)
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (username): " + username);
System.out.println("Parameter 2 (password): " + password);
System.out.println("\nDatabase will look for a user with the literal username 'admin' OR '1'='1' and the given password. This user likely won't exist. Attack thwarted!");
}
}Beyond Login: All SQL Operations
Prepared statements aren't just for SELECT queries. You should use them for ALL SQL operations that involve user input:
INSERTstatements (e.g., adding a new user)UPDATEstatements (e.g., changing a user's profile)DELETEstatements (e.g., removing data)
Always assume user input is malicious until proven otherwise. Parameterized queries are your first line of defense.
Quick Check: Secure Query
Which of the following code snippets correctly uses parameterized queries to prevent SQL Injection when searching for a product by name?
Recap: SQL Injection Prevention
Great job! In this lesson, you learned about:
- What SQL Injection is and its dangers.
- How vulnerable applications can be exploited by concatenating user input directly into SQL queries.
- The importance of using Prepared Statements (Parameterized Queries) as the primary defense mechanism.
- How prepared statements separate data from code, preventing malicious input from altering query logic.
Always use prepared statements for any SQL operation involving user input to keep your backend secure!
Preguntas frecuentes
¿La lección «Prevención de la inyección SQL» es gratis?
Sí — el texto completo de «Prevención de la inyección SQL» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Secure Coding & OWASP Top 10 for Backend, actualiza a CoddyKit PRO. El curso de Secure Coding & OWASP Top 10 for Backend incluye 4 lecciones en total.
¿Qué aprenderé en «Prevención de la inyección SQL»?
Comprenda cómo funciona la inyección SQL e implemente defensas sólidas mediante consultas parametrizadas y prepared statements. Practicas Secure Coding & OWASP Top 10 for Backend con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Secure Coding & OWASP Top 10 for Backend?
No se requiere experiencia previa. Secure Coding & OWASP Top 10 for Backend en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «Prevención de la inyección SQL»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Secure Coding & OWASP Top 10 for Backend?
Sí. Cada lección de Secure Coding & OWASP Top 10 for Backend incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Prevención de la inyección SQL
- Inyección de comandos y código
- Cross-Site Scripting (XSS) en el backend
- Prevención de inyección XML y LDAP