7.4.4. Contextes multiples de composants de message
7.4.4. Contextes multiples de composants de message
Il est possible que le contexte pour dériver les valeurs des composants de message soit distinct pour chaque signature présente dans un même message. C’est notamment le cas lorsque des proxys mutent les messages et ajoutent des signatures sur les valeurs mutées, en plus des signatures existantes. Par exemple, un proxy inverse peut remplacer dans une requête un nom d’hôte public par le nom d’hôte de l’hôte de service individuel vers lequel il transmet la requête. Si le client et le proxy inverse ajoutent tous deux des signatures couvrant @authority, l’hôte de service verra deux signatures sur la requête, chacune signant des valeurs différentes pour le composant de message @authority, reflétant la modification de ce composant pendant le transit du client vers l’hôte de service.
Dans un tel cas, il est courant que le service interne ne vérifie qu’une des signatures ou utilise des informations configurées en externe, comme indiqué à la section 7.4.3. Toutefois, un vérificateur qui traite les deux signatures doit utiliser un contexte de composant de message différent pour chaque signature, puisque la valeur du composant pour @authority différera pour chaque signature. De tels vérificateurs doivent connaître à la fois le contexte du proxy inverse pour les messages entrants et le contexte du service cible pour le message provenant du proxy inverse. Le vérificateur doit veiller en particulier à appliquer le bon contexte à la bonne signature ; sinon, un attaquant pourrait exploiter la connaissance de cette configuration complexe pour brouiller les entrées du vérificateur.
De tels vérificateurs doivent aussi s’assurer que toute différence de contexte de composants de message entre signatures est attendue et autorisée. Par exemple, dans le scénario ci-dessus, le proxy inverse pourrait inclure le nom d’hôte d’origine dans un champ d’en-tête Forwarded et pourrait signer @authority, forwarded, et l’entrée du client dans le champ Signature. Le vérificateur peut utiliser le nom d’hôte du champ Forwarded pour confirmer que la transformation du nom d’hôte s’est déroulée comme prévu.