7.5.2. Valeurs de champs sémantiquement équivalentes

7.5.2. Valeurs de champs sémantiquement équivalentes

L’algorithme de génération de la base de signature (section 2.5) utilise la valeur d’un champ HTTP comme valeur de composant. Dans le cas courant, il s’agit de prendre les octets réels de la valeur du champ comme valeur de composant pour le signataire et le vérificateur. Toutefois, certaines valeurs de champ permettent des transformations sémantiquement équivalentes qui modifient les octets de la valeur elle-même. Par exemple, une définition de champ peut déclarer une partie ou la totalité de ses valeurs comme insensibles à la casse, ou prévoir un traitement particulier des espaces blancs internes. D’autres champs subissent des transformations attendues des intermédiaires, telles que la suppression des commentaires dans le champ d’en-tête Via. Dans de tels cas, un vérificateur pourrait être piégé en utilisant la valeur de champ transformée équivalente, qui différerait des octets employés par le signataire. Le vérificateur aurait du mal à détecter cette classe d’erreurs, car la valeur du champ reste acceptable pour l’application, mais les octets exigés par la base de signature ne correspondraient pas.

Lors du traitement de tels champs, le signataire et le vérificateur doivent convenir de la façon de gérer ces transformations, le cas échéant. Une option est de ne pas signer les champs problématiques, mais il faut veiller à conserver une couverture de signature suffisante (section 7.2.1) pour l’application. Une autre option est de définir une valeur de canonicalisation propre à l’application pour le champ avant qu’il ne soit ajouté au message HTTP, par exemple toujours supprimer les commentaires internes avant de signer, ou toujours mettre les valeurs en minuscules. Comme ces transformations sont appliquées avant que le champ ne serve d’entrée à l’algorithme de génération de la base de signature, la base de signature contiendra toujours simplement la valeur en octets du champ telle qu’elle apparaît dans le message. Si les transformations devaient être appliquées après extraction de la valeur du message mais avant son ajout à la base de signature, d’autres surfaces d’attaque telles que des attaques par substitution de valeur pourraient viser l’application. Toute règle supplémentaire propre à l’application est hors du champ de cette spécification et, par nature, ces transformations nuiraient à l’interopérabilité de l’implémentation en dehors de cette application précise. Il est recommandé que les applications évitent autant que possible de telles règles supplémentaires.