7.5.6. Valeurs de champ qui ne sont pas des listes
7.5.6. Valeurs de champ qui ne sont pas des listes
Lorsqu’un champ HTTP apparaît plusieurs fois dans un même message, ces valeurs doivent être combinées en une seule valeur sur une ligne à inclure dans la base de signature HTTP, comme décrit à la section 2.5. Tous les champs HTTP ne peuvent pas être fusionnés en une seule valeur de cette façon tout en restant une valeur valide pour le champ. Aux fins de génération de la base de signature, la valeur du composant de message n’est jamais destinée à être relue depuis la chaîne de base de signature ni utilisée dans l’application. Il est donc considéré comme une bonne pratique de traiter l’algorithme de génération de la base de signature séparément du traitement des valeurs de champ par l’application, en particulier pour les champs connus pour avoir cette propriété. Si les valeurs de champ signées ne sont pas valides, le message signé devrait aussi être rejeté.
Si un champ HTTP autorise des virgules non quotées dans ses valeurs, la fusion de plusieurs valeurs de champ peut conduire à une situation où deux messages sémantiquement différents produisent la même ligne dans une base de signature. Par exemple, considérons le champ d’en-tête hypothétique suivant avec une virgule interne dans sa syntaxe, ici utilisé pour définir deux listes distinctes de valeurs :
Example-Header: value, with, lots Example-Header: of, commas
Pour ce champ d’en-tête, envoyer toutes ces valeurs comme une seule valeur de champ produit une seule liste de valeurs :
Example-Header: value, with, lots, of, commas
Ces deux messages créeraient la ligne suivante dans la base de signature :
"example-header": value, with, lots, of, commas
Comme deux entrées sémantiquement distinctes peuvent créer la même sortie dans la base de signature, un soin particulier doit être pris lors du traitement de telles valeurs.
En particulier, le champ Set-Cookie [COOKIE] définit une syntaxe interne qui ne se conforme pas à la syntaxe List fournie dans [STRUCTURED-FIELDS]. Certaines parties autorisent notamment des virgules non quotées, et le champ est typiquement envoyé comme plusieurs lignes de champ distinctes avec des valeurs distinctes lors de l’envoi de plusieurs cookies. Lorsque plusieurs champs Set-Cookie sont envoyés dans le même message, il n’est généralement pas possible de les fusionner en une seule ligne tout en pouvant analyser et utiliser les résultats, comme indiqué dans [HTTP], section 5.3. Tous les cookies doivent donc être traités à partir de leurs valeurs de champ séparées, sans fusion, tandis que la base de signature doit être traitée à partir de la valeur combinée spéciale générée uniquement à cette fin. Si la valeur du cookie est invalide, le message signé devrait être rejeté, car il s’agit d’une attaque par remplissage possible telle que décrite à la section 7.5.7.
Pour y remédier, une application peut choisir de limiter la signature de champs problématiques comme Set-Cookie, par exemple n’inclure le champ dans une signature que lorsqu’une seule valeur de champ est présente et que les résultats seraient non ambigus. Une prudence similaire s’impose pour tous les champs susceptibles d’avoir des correspondances non déterministes vers la base de signature. Les signataires peuvent aussi utiliser le paramètre bs pour protéger de tels champs, comme décrit à la section 2.1.3.