CRLF (%0D%0A) Injection
Last updated
Last updated
Conseil de prime à la faille : inscrivez-vous à Intigriti, une plateforme de prime à la faille premium créée par des pirates informatiques, pour des pirates informatiques ! Rejoignez-nous sur https://go.intigriti.com/hacktricks aujourd'hui et commencez à gagner des primes allant jusqu'à 100 000 $ !
Le retour chariot (CR) et le saut de ligne (LF), collectivement connus sous le nom de CRLF, sont des séquences de caractères spéciaux utilisées dans le protocole HTTP pour indiquer la fin d'une ligne ou le début d'une nouvelle. Les serveurs Web et les navigateurs utilisent CRLF pour distinguer entre les en-têtes HTTP et le corps d'une réponse. Ces caractères sont universellement utilisés dans les communications HTTP/1.1 sur différents types de serveurs Web, tels que Apache et Microsoft IIS.
L'injection CRLF implique l'insertion des caractères CR et LF dans une entrée fournie par l'utilisateur. Cette action induit en erreur le serveur, l'application ou l'utilisateur en interprétant la séquence injectée comme la fin d'une réponse et le début d'une autre. Bien que ces caractères ne soient pas intrinsèquement nocifs, leur mauvais usage peut entraîner des divisions de réponse HTTP et d'autres activités malveillantes.
Considérez un fichier journal dans un panneau d'administration qui suit le format : IP - Heure - Chemin visité. Une entrée typique pourrait ressembler à :
Un attaquant peut exploiter une injection CRLF pour manipuler ce journal. En injectant des caractères CRLF dans la requête HTTP, l'attaquant peut modifier le flux de sortie et fabriquer des entrées de journal. Par exemple, une séquence injectée pourrait transformer l'entrée de journal en :
Voici, %0d et %0a représentent les formes encodées en URL de CR et LF. Après l'attaque, le journal afficherait de manière trompeuse:
L'attaquant camoufle ainsi ses activités malveillantes en faisant apparaître que le localhost (une entité généralement de confiance dans l'environnement du serveur) a effectué les actions. Le serveur interprète la partie de la requête commençant par %0d%0a comme un seul paramètre, tandis que le paramètre restrictedaction est analysé comme une autre entrée distincte. La requête manipulée imite efficacement une commande administrative légitime : /index.php?page=home&restrictedaction=edit
Le fractionnement de réponse HTTP est une vulnérabilité de sécurité qui survient lorsqu'un attaquant exploite la structure des réponses HTTP. Cette structure sépare les en-têtes du corps en utilisant une séquence de caractères spécifique, un retour chariot (CR) suivi d'une avance de ligne (LF), collectivement appelé CRLF. Si un attaquant parvient à insérer une séquence CRLF dans un en-tête de réponse, il peut manipuler efficacement le contenu de la réponse suivante. Ce type de manipulation peut entraîner de graves problèmes de sécurité, notamment les attaques de type Cross-site Scripting (XSS).
L'application définit un en-tête personnalisé comme ceci : X-Custom-Header: UserInput
L'application récupère la valeur pour UserInput à partir d'un paramètre de requête, disons "user_input". Dans les scénarios sans validation et encodage d'entrée appropriés, un attaquant peut créer une charge utile qui inclut la séquence CRLF, suivie d'un contenu malveillant.
Un attaquant crée une URL avec un 'user_input' spécialement conçu : ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
Dans cette URL, %0d%0a%0d%0a est la forme encodée en URL de CRLFCRLF. Cela trompe le serveur en insérant une séquence CRLF, faisant en sorte que le serveur traite la partie suivante comme le corps de la réponse.
Le serveur reflète l'entrée de l'attaquant dans l'en-tête de réponse, entraînant une structure de réponse non intentionnelle où le script malveillant est interprété par le navigateur comme faisant partie du corps de la réponse.
Navigateur vers:
Et le serveur répond avec l'en-tête :
Autre exemple: (de https://www.acunetix.com/websitesecurity/crlf-injection/)
Vous pouvez envoyer la charge utile à l'intérieur du chemin de l'URL pour contrôler la réponse du serveur (exemple provenant de ici):
Consultez plus d'exemples sur:
L'injection d'en-tête HTTP, souvent exploitée via l'injection CRLF (Retour chariot et saut de ligne), permet aux attaquants d'insérer des en-têtes HTTP. Cela peut compromettre les mécanismes de sécurité tels que les filtres XSS (Cross-Site Scripting) ou la politique SOP (Same-Origin Policy), conduisant potentiellement à un accès non autorisé à des données sensibles, telles que des jetons CSRF, ou à la manipulation des sessions utilisateur via l'implantation de cookies.
Un attaquant peut injecter des en-têtes HTTP pour activer CORS (Cross-Origin Resource Sharing), contournant ainsi les restrictions imposées par SOP. Cette violation permet à des scripts provenant d'origines malveillantes d'interagir avec des ressources d'une origine différente, potentiellement accédant à des données protégées.
L'injection CRLF peut être utilisée pour créer et injecter une toute nouvelle requête HTTP. Un exemple notable de cela est la vulnérabilité dans la classe SoapClient de PHP, spécifiquement dans le paramètre user_agent. En manipulant ce paramètre, un attaquant peut insérer des en-têtes supplémentaires et du contenu de corps, voire injecter entièrement une nouvelle requête HTTP. Voici un exemple en PHP illustrant cette exploitation:
Pour plus d'informations sur cette technique et les problèmes potentiels consultez la source originale.
Vous pouvez injecter des en-têtes essentiels pour vous assurer que le serveur garde la connexion ouverte après avoir répondu à la requête initiale:
Après, une deuxième requête peut être spécifiée. Ce scénario implique généralement la contrebande de requête HTTP, une technique où des en-têtes supplémentaires ou des éléments de corps ajoutés par le serveur post-injection peuvent entraîner divers exploits de sécurité.
Exploitation:
Injection de Préfixe Malveillant: Cette méthode implique de polluer la prochaine requête de l'utilisateur ou un cache web en spécifiant un préfixe malveillant. Un exemple de ceci est :
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%a HTTP/1.1
Création d'un Préfixe pour l'Empoisonnement de la File de Réponses: Cette approche implique de créer un préfixe qui, combiné avec des données inutiles, forme une deuxième requête complète. Cela peut déclencher un empoisonnement de la file de réponses. Un exemple est :
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
Memcache est un magasin clé-valeur qui utilise un protocole en texte clair. Plus d'informations dans :
11211 - Pentesting MemcachePour plus d'informations, consultez le article original
Si une plateforme prend des données d'une requête HTTP et les utilise sans les désinfecter pour effectuer des requêtes vers un serveur memcache, un attaquant pourrait abuser de ce comportement pour injecter de nouvelles commandes memcache.
Par exemple, dans la vulnérabilité découverte initialement, des clés de cache étaient utilisées pour renvoyer l'IP et le port auquel un utilisateur devait se connecter, et les attaquants pouvaient injecter des commandes memcache qui empoisonnaient le cache pour envoyer les détails des victimes (noms d'utilisateur et mots de passe inclus) aux serveurs des attaquants :
De plus, les chercheurs ont également découvert qu'ils pouvaient désynchroniser les réponses memcache pour envoyer les adresses IP et les ports des attaquants aux utilisateurs dont l'email n'était pas connu de l'attaquant :
Pour atténuer les risques d'injections CRLF (Retour chariot et Saut de ligne) ou d'en-têtes HTTP dans les applications web, les stratégies suivantes sont recommandées :
Éviter les Entrées Utilisateur Directes dans les En-têtes de Réponse : La meilleure approche est de s'abstenir d'incorporer directement les entrées fournies par l'utilisateur dans les en-têtes de réponse.
Encoder les Caractères Spéciaux : Si éviter les entrées utilisateur directes n'est pas possible, assurez-vous d'utiliser une fonction dédiée à l'encodage des caractères spéciaux comme CR (Retour chariot) et LF (Saut de ligne). Cette pratique empêche la possibilité d'injection CRLF.
Mettre à Jour le Langage de Programmation : Mettez régulièrement à jour le langage de programmation utilisé dans vos applications web vers la dernière version. Optez pour une version qui interdit intrinsèquement l'injection de caractères CR et LF dans les fonctions chargées de définir les en-têtes HTTP.
Feuille de triche à partir d'ici
Conseil de prime de bug: inscrivez-vous sur Intigriti, une plateforme de prime de bug premium créée par des hackers, pour des hackers! Rejoignez-nous sur https://go.intigriti.com/hacktricks aujourd'hui, et commencez à gagner des primes allant jusqu'à 100 000 $!
