7.4.3. Source et contexte des composants de message
7.4.3. Source et contexte des composants de message
Le contexte de signature pour dériver les valeurs des composants de message inclut le message HTTP cible lui-même, tout message associé (tel que la requête ayant déclenché une réponse), et les informations supplémentaires auxquelles le signataire ou le vérificateur a accès. Signataires et vérificateurs doivent examiner avec soin la source de toutes les informations lors de la création des valeurs de composants pour la base de signature, et veiller à ne pas prendre d’informations provenant de sources non fiables. Sinon, un attaquant pourrait exploiter un contexte de message trop lâche pour injecter ses propres valeurs dans la chaîne de base de signature, remplaçant ou corrompant les valeurs voulues.
Par exemple, dans la plupart des situations, l’URI cible du message est telle que définie dans [HTTP], section 7.1. Supposons toutefois une application qui exige la signature de @authority de la requête entrante, alors que l’application de traitement se trouve derrière un proxy inverse. Une telle application s’attendrait à un changement de la valeur @authority, et pourrait être configurée pour connaître l’URI cible externe telle que vue par le client de l’autre côté du proxy. Cette application utiliserait cette valeur configurée comme URI cible aux fins de dérivation des valeurs de composants de message telles que @authority, au lieu d’utiliser l’URI cible du message entrant.
Cette approche n’est pas sans risques : un système mal configuré pourrait accepter des requêtes signées destinées à d’autres composants du système. Pour ce scénario, un intermédiaire pourrait à la place ajouter sa propre signature à vérifier directement par l’application, comme illustré à la section 4.3. Cette approche alternative exige un intermédiaire plus actif mais repose moins sur la connaissance par l’application cible de valeurs de configuration externes.
Comme autre exemple, la section 2.4 définit une méthode pour signer des messages de réponse tout en incluant des parties de la requête ayant déclenché la réponse. Dans ce cas, le contexte pour le calcul des valeurs de composants est la combinaison des messages de réponse et de requête, pas seul le message auquel la signature est appliquée. Pour cette fonctionnalité, l’indicateur req permet aux deux signataires de signaler explicitement quelle partie du contexte fournit la valeur pour un identifiant de composant. Les implémentations doivent s’assurer que seul le message voulu est visé pour chaque composant ; sinon, un attaquant pourrait tenter de subvertir une signature en manipulant l’un ou l’autre côté.