Secure Coding & OWASP Top 10 for Backend · Lektion

Schutz vor SQL-Injection

Verstehen Sie, wie SQL-Injection funktioniert, und implementieren Sie robuste Schutzmaßnahmen mit parametrisierten Queries und Prepared Statements.

Schutz vor SQL-Injection ist eine kostenlose Secure Coding & OWASP Top 10 for Backend-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Secure Coding & OWASP Top 10 for Backend-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Secure Coding & OWASP Top 10 for Backend-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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:

INSERT statements (e.g., adding a new user)
UPDATE statements (e.g., changing a user's profile)
DELETE statements (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!

Häufig gestellte Fragen

Ist die Lektion „Schutz vor SQL-Injection“ kostenlos?

Ja — der vollständige Text von „Schutz vor SQL-Injection“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Secure Coding & OWASP Top 10 for Backend-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Secure Coding & OWASP Top 10 for Backend-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Schutz vor SQL-Injection“?

Verstehen Sie, wie SQL-Injection funktioniert, und implementieren Sie robuste Schutzmaßnahmen mit parametrisierten Queries und Prepared Statements. Du übst Secure Coding & OWASP Top 10 for Backend mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Secure Coding & OWASP Top 10 for Backend zu starten?

Keine Vorkenntnisse erforderlich. Secure Coding & OWASP Top 10 for Backend auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Schutz vor SQL-Injection“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Secure Coding & OWASP Top 10 for Backend-Lektion Code schreiben und ausführen?

Ja. Jede Secure Coding & OWASP Top 10 for Backend-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Secure Coding & OWASP Top 10 for Backend