Sécurité des applications Kotlin : top 10 des vulnérabilités en pratique

Sécurité des applications Kotlin : top 10 des vulnérabilités en pratique

Kotlin occupe solidement la position de l'un des langages les plus populaires pour le développement d'applications Android et serveur. Cependant, comme tout autre langage, Kotlin n'est pas à l'abri des vulnérabilités. Dans cet article, nous analyserons les 10 problèmes de sécurité les plus critiques rencontrés par les développeurs et montrerons comment les éviter en pratique.

1. Injections SQL (SQL Injection)

Bien que Kotlin soit souvent utilisé avec des bibliothèques ORM, le travail direct avec des requêtes SQL reste une pratique courante.

Code vulnérable :

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

Version sécurisée (utilisation de PreparedStatement) :

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

Conclusion : Ne concaténez jamais les entrées utilisateur dans des requêtes SQL. Utilisez des requêtes paramétrées ou un ORM (Exposed, Hibernate).

2. Cross-Site Scripting (XSS) dans les applications Web

Lors du développement d'applications serveur avec Ktor ou Spring Boot, on oublie souvent d'échapper la sortie.

Code vulnérable (Ktor) :

get("/user/{name}") {    val name = call.parameters["name"] ?: "Invité"    call.respondText("<h1>Bonjour, $name!</h1>", ContentType.Text.Html)}

Version sécurisée :

import org.apache.commons.text.StringEscapeUtils

get("/user/{name}") {    val name = call.parameters["name"] ?: "Invité"    val safeName = StringEscapeUtils.escapeHtml4(name)    call.respondText("<h1>Bonjour, $safeName!</h1>", ContentType.Text.Html)}

Conseil : Échappez toujours les entrées utilisateur avant de les afficher en HTML. Utilisez des moteurs de templates avec échappement automatique (par exemple, Kotlinx.html).

3. Stockage non sécurisé des mots de passe

Stocker les mots de passe en clair ou avec des hachages faibles est l'une des erreurs les plus fréquentes.

Approche incorrecte :

fun savePassword(password: String) {    val hash = password.md5() // Ne faites jamais cela !    database.saveHash(hash)}

Approche correcte (bcrypt) :

import at.favre.lib.crypto.bcrypt.BCrypt

fun savePassword(password: String) {    val hash = BCrypt.withDefaults().hashToString(12, password.toCharArray())    database.saveHash(hash)}

fun checkPassword(password: String, storedHash: String): Boolean {    return BCrypt.verifyer().verify(password.toCharArray(), storedHash).verified}

Important : Utilisez bcrypt, scrypt ou Argon2. N'utilisez jamais MD5 ou SHA-1 pour stocker les mots de passe.

4. Fuite de données confidentielles via les logs

Les développeurs journalisent souvent des données sensibles sans vérifier ce qui se retrouve dans la sortie.

Code problématique :

logger.info("Utilisateur $userId authentifié avec le token : $token")

Version sécurisée :

logger.info("Utilisateur $userId authentifié avec succès")// Ou utilisez le masquage :fun maskToken(token: String): String =     token.take(4) + "****" + token.takeLast(4)

Règle : Ne journalisez jamais les mots de passe, tokens, numéros de carte de crédit ou données personnelles. Utilisez des bibliothèques de masquage (par exemple, Logstash).

5. Désérialisation non sécurisée

Kotlin utilise activement la sérialisation JSON. Une configuration incorrecte peut entraîner des attaques RCE.

Code vulnérable (Jackson) :

val mapper = ObjectMapper()val obj = mapper.readValue(userInput, Any::class.j