Simple ne signifie pas toujours sécurisé : évitez ce schéma XSS en Golang

Les attaques par script intersites (XSS) sont une vulnérabilité Web courante qui permet aux attaquants d’injecter des scripts malveillants dans des pages consultées par d’autres utilisateurs. On pourrait penser qu’un code plus simple est plus sûr : aucune dépendance tierce, moins d’abstractions. Cela semble idéal, mais est-ce vraiment le cas ?

Cet article présente un serveur Web simple écrit en Golang et explique pourquoi simplicité ne rime pas toujours avec sécurité.

À propos des attaques par script intersites

Les scripts utilisés lors d’attaques par script intersites (XSS) servent souvent à dérober des données utilisateur, détourner des sessions ou défigurer des sites Web. Golang offre des outils robustes pour le développement Web, mais n’est pas à l’abri des vulnérabilités XSS si les précautions nécessaires ne sont pas prises.

Exemple de script intersite en Golang

Les vulnérabilités XSS proviennent souvent de l’insertion directe de données fournies par l’utilisateur dans le code HTML, sans assainissement adéquat ni autres mesures de sécurité. À noter : une mesure de sécurité efficace n’est pas toujours l’assainissement ; il peut s’agir de l’encodage de sortie.

Prenons l’exemple d’une application Go qui reçoit des données d’un utilisateur via un champ de formulaire ou un paramètre d’URL (comme une chaîne de requête), puis les insère directement dans une page HTML incluse dans la réponse HTTP. Un attaquant pourrait injecter du code JavaScript malveillant (d’où le nom « script intersite »). Lorsqu’un autre utilisateur consulte la page, son navigateur exécute le script injecté, ce qui peut compromettre ses données ou sa session.

Dans les serveurs HTTP Golang, une erreur fréquente consiste à utiliser fmt.Fprint ou des fonctions similaires pour écrire directement les données fournies par l’utilisateur dans la réponse HTTP. Considérez l’extrait de code suivant :

http.HandleFunc("/greet", func(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    response := fmt.Sprintf("<html><body><h1>Hello, %s!</h1></body></html>", name)
    fmt.Fprint(w, response)
})

Si un utilisateur définit la chaîne de requête name sur une valeur telle que <script>alert('XSS!')</script>, ce code injectera le code JavaScript alert() dans la page, illustrant une attaque XSS élémentaire. La fonction fmt.Sprintf n’échappe pas automatiquement les entités HTML, ce qui rend l’application vulnérable.

Cet extrait de code Golang provient d’un défi de sécurité open source. Snyk a importé ce dépôt de code et a détecté la présence de données non assainies provenant de l’URL de la requête, ainsi que leur transmission à l’appel non sécurisé de la fonction fmt.Fprint, qui génère la chaîne du modèle HTML. L’analyse complète du code source et de son cheminement par le SAST de Snyk présente les résultats plus en détail :

Comment corriger les XSS en Golang

L’exemple vulnérable en Golang ci-dessus montre qu’il faut échapper ou assainir correctement les données saisies par l’utilisateur avant de les inclure dans des réponses HTML.

Échapper du code HTML potentiellement dangereux signifie que le code de l’application, ou la dépendance tierce utilisée, doit encoder certaines données saisies par l’utilisateur afin qu’elles ne soient pas interprétées comme des éléments du DOM HTML. Par exemple, les frameworks frontend comme React ou Vue convertissent le caractère < en son entité HTML équivalente, <.

Faut-il toujours s’appuyer sur des dépendances tierces ? Non, mais si vous les surveillez et les analysez activement pour détecter les vulnérabilités, et les maintenez à jour grâce à des mises à jour automatisées, il est plus facile de maîtriser les risques de sécurité. Reste également le risque d’utiliser la bibliothèque de manière inadéquate et d’introduire malgré tout une vulnérabilité.

Et qu’en est-il des problèmes de sécurité du code en Golang ? Snyk prend largement en charge Go, notamment le code, les dépendances et les gestionnaires de packages.