7.5.1. Traiter des noms de champs HTTP invalides comme noms de composants dérivés

7.5.1. Traiter des noms de champs HTTP invalides comme noms de composants dérivés

La définition des noms de champs HTTP n’autorise pas l’usage du caractère @ nulle part dans le nom. Ainsi, comme tous les noms de composants dérivés commencent par le caractère @, ces espaces de noms devraient être complètement disjoints. Toutefois, certaines implémentations HTTP ne sont pas assez strictes sur les caractères acceptés dans les noms de champs HTTP. Dans de telles implémentations, un expéditeur (ou un attaquant) pourrait injecter un champ d’en-tête commençant par @ et le faire parvenir au code applicatif. Ces champs d’en-tête invalides pourraient servir à remplacer une partie du contenu de message dérivé et substituer une valeur arbitraire, offrant un point d’appui potentiel pour une attaque par collision de signature (section 7.3.1) ou une autre attaque par substitution fonctionnelle (par exemple utiliser la signature d’une requête GET sur une requête POST fabriquée).

Pour s’en prémunir, lors du choix des valeurs d’un composant de message, si le nom du composant commence par le caractère @, il doit être traité comme un composant dérivé et jamais comme un champ HTTP. Ce n’est que si le nom ne commence pas par @ qu’il peut être pris dans les champs du message. L’algorithme décrit à la section 2.5 fournit un ordre d’opérations sûr.