7.4.4. Contesti multipli dei componenti del messaggio (Multiple Message Component Contexts)

7.4.4. Contesti multipli dei componenti del messaggio (Multiple Message Component Contexts)

È possibile che il contesto per derivare i valori dei componenti del messaggio sia distinto per ogni firma presente in un singolo messaggio. Ciò vale in particolare quando i proxy mutano i messaggi e includono firme sui valori mutati, oltre a eventuali firme esistenti. Ad esempio, un reverse proxy può sostituire in una richiesta un hostname pubblico con l'hostname dell'host di servizio individuale a cui sta inoltrando la richiesta. Se sia il client sia il reverse proxy aggiungono firme che coprono @authority, l'host di servizio vedrà due firme sulla richiesta, ciascuna che firma valori diversi per il componente del messaggio @authority, riflettendo la modifica a quel componente mentre il messaggio procedeva dal client all'host di servizio.

In tal caso, è comune che il servizio interno verifichi solo una delle firme o usi informazioni configurate esternamente, come discusso nella Sezione 7.4.3. Tuttavia, un verificatore che elabora entrambe le firme deve usare un contesto di componente del messaggio diverso per ciascuna firma, poiché il valore del componente per @authority sarà diverso per ogni firma. Verificatori di questo tipo devono essere consapevoli sia del contesto del reverse proxy per i messaggi in ingresso sia del contesto del servizio di destinazione per il messaggio proveniente dal reverse proxy. Il verificatore deve prestare particolare cura ad applicare il contesto corretto alla firma corretta; altrimenti un attaccante potrebbe usare la conoscenza di questa configurazione complessa per confondere gli input al verificatore.

Tali verificatori devono anche garantire che eventuali differenze nei contesti dei componenti del messaggio tra le firme siano attese e consentite. Ad esempio, nello scenario sopra, il reverse proxy potrebbe includere l'hostname originale in un campo Forwarded e potrebbe firmare @authority, forwarded e la voce del client nel campo Signature. Il verificatore può usare l'hostname dal campo Forwarded per confermare che l'hostname è stato trasformato come atteso.