SQL Injection – Die häufigste Web-Schwachstelle erklärt

Stell dir vor, du hast eine einfache Login-Form. Der Code sieht so aus: ```python username = request.form.get("username") password = request.form.get("password") query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'" result = execute_query(query) ``` Alles normal, oder? Der Benutzer gibt seinen Username und Passwort ein, die werden in die SQL-Query eingefügt, und die Datenbank gibt zurück ob es einen Match gibt. Aber: Was ist wenn der Benutzer statt eines normalen Usernames etwas böses eingibt? ``` username: admin' -- password: whatever ``` Die generierte Query wird: ```sql SELECT * FROM users WHERE username = 'admin' --' AND password = 'whatever' ``` Beachte das `--`. In SQL ist das ein Kommentar. Alles danach wird ignoriert. Also wird die Query zu: ```sql SELECT * FROM users WHERE username = 'admin' ``` Und boom: Der Attacker loggt sich als Admin ein, ohne das Passwort zu wissen. Das ist SQL Injection in seiner einfachsten Form.

Weil Entwickler diesen mistake machen: ```python # FALSCH – Vulnerable: query = f"SELECT * FROM users WHERE email = '{email}'" ``` Das ist so einfach – und es funktioniert für normale Inputs. Ein Entwickler sieht keinen Grund, es zu ändern. Aber ein Hacker findet die Lücke sofort.

Python: ```python cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) ``` PHP: ```php $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$user_id]); ``` JavaScript/Node: ```javascript connection.query('SELECT * FROM users WHERE id = ?', [userId], callback); ``` Java: ```java PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE id = ?"); stmt.setInt(1, userId); ``` Alle modernen Frameworks haben Prepared Statements. Kein Grund, sie nicht zu nutzen.

Einige Entwickler denken, sie können sich schützen durch Input-Filtering: ```python # FALSCH – Unsicher: email = email.replace("'", "") # Remove quotes query = f"SELECT * FROM users WHERE email = '{email}'" ``` Das ist nicht sicher. Ein Attacker kann Wege finden, um die Filter zu bypass. Prepared Statements ist der einzige sichere Weg.