Le machine learning peut-il détecter les vulnérabilités de traversée de chemin en Go ? Snyk Code, oui !

Qui n’aime pas relever un bon défi de sécurité ? Moi, en tout cas, mais pensez-vous qu’un algorithme de machine learning soit capable de détecter les vulnérabilités de traversée de chemin ? Vérifions-le !

Ces dernières semaines, Zeyad AbuLaban a publié une série d’articles sur la sécurité du code et les vulnérabilités. Dans sa série « Secure Code Quest », il présente différents types de vulnérabilités dans différents langages.

Quand Zeyad a publié son Secure Code Quest n° 5, au lieu de me précipiter sur le code de l’image pour tenter d’y repérer les pratiques non sécurisées, une autre idée m’est venue : « Si je colle ce code Go dans mon IDE et que je l’analyse avec mon extension Snyk pour VS Code, pourra-t-elle le détecter ? »

Ce code Golang est-il vulnérable ?

Commençons par mettre ce code Go en forme pour l’examiner plus attentivement dans le cadre d’une revue de code en bonne et due forme.

Ce programme Golang manipule des fichiers et comprend donc une fonction downloadHandler() qui sert de contrôleur HTTP. Elle attend un filename dans le paramètre de requête, puis nettoie et sécurise le chemin. Elle construit ensuite le chemin d’accès à un dossier de stockage sur le disque (baseDir := “public/files/”) en concaténant le nom de fichier au répertoire racine.

package main

import (
    // ... imports ...
)

func main() {
    // ... main function code ...
}

func downloadHandler(w http.ResponseWriter, r *http.Request) {
    filename := r.URL.Query().Get("filename")
    if filename == "" {
        http.Error(w, "Missing filename parameter", http.StatusBadRequest)
        return
    }

    // Preventing Path Traversal
    sanitizedFilename := strings.Replace(filename, "../", "", -1)
    cleanedFilename := filepath.Clean(sanitizedFilename)

    baseDir := "public/files/"
    fullPath := filepath.Join(baseDir, cleanedFilename)

    // ... code to handle file serving ...
}

Comment ce programme Go met-il en œuvre ses contrôles de sécurité ? Il utilise une opération de remplacement de chaîne pour remplacer toutes les occurrences de ../ dans le nom de fichier par une chaîne vide, les supprimant ainsi complètement de la valeur fournie par l’utilisateur.

Imaginons la requête HTTP suivante :

curl "http://localhost:8080/download?filename=../../app/flag.txt

Cette requête HTTP assainit la variable filename en supprimant tous les chemins ../. La valeur filename se limite alors à app/flag.txt. Elle est ensuite concaténée au chemin baseDir, ce qui donne le chemin complet public/files/app/flag.txt.

Alors, comment contourner cette protection ?

Comment construire la requête HTTP pour récupérer le fichier /app/flag.txt du défi Capture the Flag et remporter le prix ?

Avant de vous révéler la charge utile, voyons ce qui se passe quand vous collez ce programme Golang dans l’IDE.

Sécuriser le code grâce au machine learning

J’ai d’abord ajouté cette logique comme nouvelle route dans mon application web utilisant Gin, d’où la déclaration de route légèrement différente. Vous pouvez ensuite voir que j’ai complété le code après la variable fullPath pour vérifier que le fichier est valide, puis l’envoyer au client.

Imaginez maintenant que l’extension Snyk est installée dans votre IDE.

Il vous suffit d’enregistrer le fichier et, quelques secondes plus tard (oui, vraiment quelques secondes), vous obtenez un audit de sécurité du code qui analyse votre code source, ainsi que ses dépendances, le Dockerfile, Terraform, etc.

En plus de vous fournir un rapport de sécurité, l’extension Snyk pour IDE met également en évidence la ligne de code vulnérable, à la manière d’un linter. Elle vous donne aussi accès à des outils pour approfondir le problème de sécurité :

• Le nom et les détails de la vulnérabilité.

• Le flux de données de la source au point d’utilisation montre comment des données non assainies atteignent des API sensibles.

• Pour en savoir plus sur cette vulnérabilité de traversée de chemin si vous en entendez parler pour la première fois.

• Des exemples de code correctif à appliquer si vous ne savez pas comment corriger cette vulnérabilité.

Dans certains cas, Snyk propose également Snyk Agent Fix, qui corrige automatiquement le problème de sécurité en refactorisant le code pour éliminer la vulnérabilité tout en préservant votre logique.

Quel est le rôle du machine learning dans tout cela ? Eh bien, il est essentiel.

L’analyse SAST (test de sécurité statique des applications) de Snyk examine votre code source, puis le soumet au moteur de machine learning propriétaire de Snyk. Ce moteur de sécurité repose sur un algorithme robuste d’IA symbolique, entraîné sur de grandes bases de code. Il a appris à reconnaître les modèles de code non sécurisés, classés et étiquetés par des experts en sécurité lors d’un processus d’ajustement fin.

Ce processus technique poussé s’exécute en quelques secondes, directement dans mon IDE, et détecte les vulnérabilités dans mon code avec une rapidité et une précision inégalées. Le moteur a également été entraîné à reconnaître ce qui constitue du « bon code » et a analysé de véritables corrections de sécurité dans des dépôts open source afin de proposer des exemples de code corrigé que je peux appliquer si je ne sais pas exactement comment procéder.

La combinaison d’algorithmes de machine learning génératif et d’IA symbolique permet à Snyk d’offrir une expérience extrêmement efficace pour détecter les vulnérabilités du code. Découvrez comment Snyk garantit une adoption sûre de l’IA.

Exploiter Golang pour une traversée de chemin

Revenons à notre défi de sécurité. Comment exploiter la traversée de chemin dans le programme Golang présenté et récupérer le flag ?

Pour rappel, voici la logique de prévention de la traversée de chemin dans le programme Golang :

    // Preventing Path Traversal
    sanitizedFilename := strings.Replace(filename, "../", "", -1)
    cleanedFilename := filepath.Clean(sanitizedFilename)

Le remplacement de chaîne recherche une correspondance exacte avec le texte ../. Ainsi, si le nom de fichier contient une séquence classique de traversée de chemin, comme « ../ », celle-ci sera remplacée.

Mais que se passe-t-il si nous modifions la séquence de traversée de chemin pour contourner cette recherche exacte ? Voici une charge utile HTTP avec une valeur filename modifiée :

curl "http://localhost:8080/download?filename=....//....//app/flag.txt

Lorsque la valeur du paramètre de requête filename est ....//....//app/flag.txt,, les occurrences de « ../ » sont détectées (elles se trouvent dans la chaîne du nom de fichier) et supprimées. Il reste alors les séquences « .. » et les « / » isolés dans le nom de fichier. La valeur sanitizedFilename devient ../../app/flag.txt, ce qui sort du répertoire de base (public/files/) et envoie le fichier flag.txt au client.