Les développeurs à la conquête de la sécurité : Série Partage & Apprentissage - Injection CRLF

Dans les blogs ou les articles comme celui-ci, la ponctuation aide le lecteur. Par exemple, les points indiquent la fin d'une phrase, tandis que les virgules séparent les éléments d'une liste ou marquent des pauses pour structurer les idées. Dans un article bien rédigé (comme celui-ci), la ponctuation est presque invisible, faisant partie intégrante du code de base que nous avons tous appris à traiter il y a bien longtemps.

Mais que se passe-t-il si un pirate informatique accède à cet article et insère des signes de ponctuation étranges aux mauvais endroits ? Comme ceci :

Sans,même! changer. le, texte. cela? peut. rendre! beaucoup? plus. difficile? à! traiter! les, informations!

C'est essentiellement ce qui se produit lors d'une attaque par injection CRLF. Les lettres CRLF signifient « Carriage Return » (retour chariot) et « Line Feed » (saut de ligne), utilisés seuls ou ensemble pour marquer la fin d'une ligne. Si un attaquant parvient à insérer un code CR ou LF dans une application existante, il peut parfois en modifier le comportement. Les effets sont moins prévisibles que pour la plupart des autres attaques, mais peuvent être tout aussi dangereux pour l'organisation visée.

Dans cet épisode, nous apprendrons :

• Comment les attaquants peuvent déclencher une injection CRLF
• Pourquoi les injections CRLF sont dangereuses
• Techniques pour corriger cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection CRLF ?

Injecter des caractères CRLF dans un code existant pour obtenir un résultat spécifique est assez difficile, bien que possible. La tâche est d'autant plus complexe qu'un attaquant doit utiliser différentes combinaisons de CRLF selon le système d'exploitation et d'autres facteurs propres au système ciblé. Par exemple, les machines Windows modernes nécessitent à la fois un CR et un LF pour terminer une ligne, tandis que sous Linux, seul le code LF est requis. Les requêtes HTTP exigent toujours un code CRLF précis pour terminer une ligne.

Au-delà du fait que les attaques CRLF sont difficiles à mettre en œuvre et que leurs résultats sont encore plus imprévisibles, elles sont initiées de la même manière que d'autres types d'attaques par injection. Un utilisateur malveillant saisit simplement des données dans n'importe quelle zone d'un site web ou d'une application qui le permet, en insérant le code CRLF à la place ou à la suite des données normales.

Par exemple, un attaquant pourrait saisir le code ASCII représentant un retour chariot (%0d) suivi du code ASCII pour un saut de ligne (%0a) à la fin d'un en-tête HTTPS. La requête complète ressemblerait alors à ceci :

https://validsite.com/index.php?page=home%0d%0a

Si les données ne sont ni assainies ni filtrées, le code ci-dessus pourrait provoquer des comportements anormaux sur l'application ou le site web cible.

Pourquoi les injections CRLF sont-elles dangereuses ?

Bien que les attaques par injection CRLF soient moins précises que la plupart des autres, elles peuvent s'avérer assez dangereuses. Dans le meilleur des cas, l'ajout d'une ligne supplémentaire peut corrompre les fichiers journaux, ce qui pourrait déclencher des défenses de cybersécurité automatiques et alerter les administrateurs pour un faux problème. Cela pourrait toutefois être utilisé pour détourner l'attention des ressources vers un incident fictif pendant qu'une intrusion réelle se produit simultanément.

Mais les attaques CRLF peuvent aussi être directement dommageables. Par exemple, si une application est conçue pour accepter des commandes puis rechercher un fichier spécifique, l'ajout d'un code CRLF à la requête pourrait amener l'application à afficher ce processus à l'écran au lieu de le garder masqué, ce qui pourrait fournir des informations précieuses à un attaquant.

Les injections CRLF peuvent également être utilisées pour créer ce que l'on appelle une attaque par fractionnement de réponse (response splitting), où les codes de fin de ligne divisent une réponse valide en plusieurs parties. Cela peut donner aux pirates le contrôle de l'en-tête après le code CRLF, ce qui peut être utilisé pour injecter du code supplémentaire. Cela peut aussi servir à créer une ouverture permettant à l'attaquant d'injecter pleinement son propre code et, probablement, de déclencher une autre forme d'attaque sur n'importe quelle ligne suivant la partie rompue par l'attaque CRLF.

Éliminer la vulnérabilité par injection CRLF

S'il y a un message clé à retenir de cette série, c'est de ne jamais, au grand jamais, faire confiance aux entrées utilisateur. La plupart des vulnérabilités que nous avons abordées dans cette série impliquent d'une manière ou d'une autre des zones de saisie utilisateur, et la faille par injection CRLF ne fait pas exception.

Partout où un utilisateur peut saisir des données, des filtres doivent être appliqués pour empêcher l'injection de code non autorisé qui pourrait être mal interprété par l'application ou le serveur. Pour les attaques CRLF, le verrouillage des en-têtes HTTP est particulièrement important, mais il ne faut pas oublier les paramètres GET et POST, ni même les cookies. Un excellent moyen d'empêcher spécifiquement les codes CRLF de faciliter d'autres injections consiste à appliquer un encodage HTML à tout ce qui est renvoyé au navigateur de l'utilisateur.

En savoir plus sur les injections CRLF

Pour aller plus loin, consultez les recommandations de l'OWASP sur les injections CRLF. Vous pouvez également mettre vos nouvelles compétences défensives à l'épreuve avec la démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir des experts en la matière. Pour en savoir plus sur la lutte contre cette vulnérabilité et bien d'autres menaces, visitez le blog de Secure Code Warrior.