FlawOpen

flawopen.com/Teardowns/cve-2022-31150-undici-crlf-injection

● CVE-2022-31150 · CVSS 5.3 · Moyenne
Recherche · FlawOpen

CVE-2022-31150 : injection CRLF dans Undici

CVE-2022-31150 laissait des CR/LF non fiables atteindre la sérialisation des requêtes Undici. Découvrez le correctif et la mise à jour.

💡 Explication en Langage Simple (ELI5)

Une requête HTTP ressemble à un formulaire dont les retours à la ligne sont définis : chaque ligne contient un champ. Si quelqu’un copie du texte sans le vérifier, un retour caché peut faire passer la suite pour un nouveau champ. Le correctif d’Undici valide les valeurs d’en-tête, la méthode et le chemin avant leur écriture.

Concepts Clés et Termes

Undici
Bibliothèque HTTP/1.1 pour Node.js ; Node.js embarque aussi une version d’Undici pour fetch.
Injection CRLF
Des octets retour chariot et saut de ligne non fiables entrent dans un champ de protocole et peuvent modifier les limites de ligne.
Jeton HTTP
Ensemble restreint de caractères utilisé par des éléments du protocole, comme les noms d’en-tête et les méthodes.
Cible de requête
Chemin et paramètres envoyés dans une requête HTTP ; les caractères de contrôle ne doivent pas modifier son cadrage.

Correspondances de référentiels

  • Référence CWE pour la faiblesse décrite dans ce guide : CWE-93

Analyse de Cause Racine

Avant le correctif, Undici pouvait sérialiser des valeurs d’en-tête influencées par des données non fiables contenant des caractères de contrôle interdits. CR/LF délimitent les lignes ; les accepter peut injecter ou corrompre des lignes d’en-tête. Le correctif valide les noms comme jetons HTTP, rejette les caractères interdits dans les valeurs, valide le jeton de méthode et bloque les caractères de contrôle dans le chemin. L’avis GitHub indique les versions du paquet antérieures à 5.8.0 ; la description du NVD mentionne celles antérieures à 5.7.1. Les deux désignent 5.8.0 comme version corrigée. Il s’agit d’une injection dans la requête cliente ; une SSRF ou l’exposition d’identifiants n’est pas automatique et dépend de l’application et du réseau.

Déroulement de l'Attaque Étape par Étape

Étape 1

1. Valeur non fiable

Des données de l’application atteignent un en-tête, une méthode ou un chemin Undici.

Étape 2

2. Validation absente

Dans les versions concernées, des caractères de contrôle interdits pouvaient parvenir à la construction de la requête.

Étape 3

3. Frontière du protocole

La sérialisation HTTP utilise des limites de ligne ; accepter ces caractères peut injecter ou corrompre des champs.

Étape 4

4. Correctif et maîtrise

Undici 5.8.0 valide les octets des en-têtes, les jetons de méthode et les caractères du chemin avant sérialisation ; l’impact dépend du contexte.

Code Source : Vulnérable vs Sécurisé

IMPLÉMENTATION VULNÉRABLE
// Point de sérialisation concerné dans lib/core/request.js avant a29a151
function serializeRequest(request, method, path, headers) {
  request.method = method;
  request.path = path;
  for (const [key, value] of Object.entries(headers)) {
    // Aucun caractère du protocole n’est validé avant la sérialisation.
    request.headers += `${key}: ${value}\r\n`;
  }
}
PATCH SÉCURISÉ ET ROBUSTE
// Modèle de validation renforcée du parseur de requêtes amont
const token = /^[!#$%&'*+\-.^_`|~0-9A-Za-z]+$/;
const invalidFieldValue = /[^\t\x20-\x7e\x80-\xff]/;
const invalidPath = /[^\u0021-\u00ff]/;

function validateRequestTarget(method, path) {
  if (!token.test(method)) throw new InvalidArgumentError('invalid request method');
  if (invalidPath.test(path)) throw new InvalidArgumentError('invalid request path');
}

function processHeader(request, key, value) {
  if (!token.test(key)) throw new InvalidArgumentError('invalid header key');
  if (invalidFieldValue.test(value)) throw new InvalidArgumentError(`invalid ${key} header`);
  request.headers += `${key}: ${value}\r\n`;
}

Liste de Contrôle de Sécurité pour l'Ingénierie

Sources