Kotlin und Sicherheit: Wie man SQL-Injection und XSS vergisst

Ihr Code im Visier: Warum Sicherheit in Kotlin keine Option, sondern eine Notwendigkeit ist

Stellen Sie sich vor: Sie haben die perfekte Anwendung geschrieben. Schönes Interface, blitzschnelle Geschwindigkeit, saubere Architektur. Aber in einer einzigen Codezeile versteckt sich eine „Hintertür“. Ein Angreifer gibt in das Suchfeld ' OR '1'='1 ein – und Ihre Datenbank steht offen wie eine Konservendose. Kommt Ihnen das bekannt vor? Wenn nicht – großartig. Aber es ist besser, im Voraus vorbereitet zu sein, als im Produktivbetrieb Brände zu löschen.

Kotlin ist eine leistungsstarke und moderne Sprache. Aber wie jedes andere Werkzeug macht es Ihren Code nicht automatisch sicher. SQL-Injection und XSS (Cross-Site Scripting) stehen seit vielen Jahren ganz oben auf der OWASP Top 10. Und Kotlin-Entwickler, die denken „Ich verwende ein ORM, mir droht keine Gefahr“, befinden sich oft in der Risikozone.

In diesem Artikel werden wir besprechen, wie Sie Ihren Kotlin-Code in eine uneinnehmbare Festung verwandeln. Kein überflüssiges Geschwafel – nur praktische Tipps, reale Beispiele und Lifehacks, die Sie noch heute anwenden können.

SQL-Injection in Kotlin: Anatomie eines Angriffs und Schutzstrategien

Wie eine Schwachstelle aussieht (und warum sie beängstigend ist)

SQL-Injection tritt auf, wenn Benutzereingaben direkt in eine SQL-Abfrage gelangen. Angenommen, Sie haben diesen Code (machen Sie das niemals!):

fun getUserById(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = '$id'"\n    val statement = connection.createStatement()\n    val result = statement.executeQuery(query)\n    // ...\n}

Wenn ein Angreifer id = "1'; DROP TABLE users; --" übergibt, führt die Datenbank Folgendes aus: SELECT * FROM users WHERE id = '1'; DROP TABLE users; --'. Und Ihre Benutzer sind verschwunden. Für immer.

Regel Nr. 1: Verwenden Sie immer parametrisierte Abfragen

Das ist der Goldstandard. Kotlin (und Java) bietet PreparedStatement, das SQL-Code und Daten trennt:

fun getUserByIdSafe(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = ?"\n    val preparedStatement = connection.prepareStatement(query)\n    preparedStatement.setString(1, id)\n    val result = preparedStatement.executeQuery()\n    // ...\n}

Die Datenbank erhält das Abfragemuster getrennt von den Daten. Selbst wenn in id schädlicher Code ankommt, wird er als Zeichenkette und nicht als Befehl interpretiert.

Regel Nr. 2: Verwenden Sie Exposed oder andere ORMs richtig

Die Bibliothek Exposed ist eine beliebte Wahl für Kotlin. Sie ist sicher, wenn Sie ihre API richtig verwenden. Schlechtes Beispiel (rohe Verkettung):

// SCHLECHT: anfällig\nval users = transaction {\n    exec("SELECT * FROM users WHERE name = '$userInput'")\n}

Gutes Beispiel (Verwendung des Exposed-DSL):

// GUT: Bereinigung ist eingebaut\nval users = transaction {\n    Users.select { Users.name eq userInput }\n}

In Exposed bereinigt der Operator eq Werte automatisch. Aber wenn Sie rohe SQL-Abfragen über exec schreiben – seien Sie wachsam.

Regel Nr. 3: Eingabevalidierung – Ihr zweiter Schutzschild

Selbst mit parametrisierten Abfragen sollten Sie nicht alles in die Datenbank lassen. Verwenden Sie die integrierten Kotlin-Mittel zur Überprüfung:

fun validateUserId(id: String): Boolean {\n    // Prüfen, ob id eine UUID oder eine ganze Zahl ist\n    return id.matches(Regex("^[a-fA-F0-9-]{36}$")) || \n           id.all { it.isDigit() }\n}

Denken Sie daran: Vertrauen Sie keiner Eingabe. Auch wenn sie von Ihrem eigenen Frontend kommt. Besonders wenn sie von Ihrem eigenen Frontend kommt.

XSS-Angriffe: Wie Sie verhindern, dass JavaScript-Code Ihre Website übernimmt

Was ist XSS und warum schützt Kotlin Sie nicht automatisch

XSS (Cross-Site Scripting) liegt vor, wenn ein Angreifer ein Skript auf Ihrer Seite einschleust. Zum Beispiel schreibt er in das Kommentarfeld: <script>alert('Ihre Daten wurden gestohlen')</script>