7.4.3. Origine e contesto dei componenti del messaggio (Message Component Source and Context)
7.4.3. Origine e contesto dei componenti del messaggio (Message Component Source and Context)
Il contesto della firma per derivare i valori dei componenti del messaggio include il messaggio HTTP di destinazione stesso, eventuali messaggi associati (come la richiesta che ha innescato una risposta) e informazioni aggiuntive a cui hanno accesso il firmatario o il verificatore. Sia i firmatari sia i verificatori devono considerare attentamente la sorgente di tutte le informazioni quando creano valori di componente per la base della firma e fare attenzione a non prendere informazioni da fonti non attendibili. Altrimenti, un attaccante potrebbe sfruttare un contesto del messaggio così lasco per iniettare propri valori nella stringa della base della firma, sovrascrivendo o corrompendo i valori intesi.
Ad esempio, nella maggior parte delle situazioni, l'URI di destinazione del messaggio è come definito in [HTTP], Sezione 7.1. Tuttavia, supponiamo che ci sia un'applicazione che richieda la firma di @authority della richiesta in ingresso, ma l'applicazione che elabora sia dietro un reverse proxy. Tale applicazione si attenderebbe un cambiamento nel valore @authority e potrebbe essere configurata per conoscere l'URI di destinazione esterno visto dal client dall'altra parte del proxy. Questa applicazione userebbe questo valore configurato come suo URI di destinazione ai fini della derivazione di valori di componenti del messaggio come @authority invece di usare l'URI di destinazione del messaggio in ingresso.
Questo approccio non è privo di problemi, poiché un sistema mal configurato potrebbe accettare richieste firmate destinate a componenti diversi nel sistema. Per questo scenario, un intermediario potrebbe invece aggiungere la propria firma da verificare direttamente dall'applicazione, come dimostrato nella Sezione 4.3. Questo approccio alternativo richiede un intermediario più attivo ma si affida meno al fatto che l'applicazione di destinazione conosca valori di configurazione esterni.
Come altro esempio, la Sezione 2.4 definisce un metodo per firmare messaggi di risposta includendo anche porzioni del messaggio di richiesta che hanno innescato la risposta. In questo caso, il contesto per il calcolo del valore del componente è la combinazione dei messaggi di risposta e richiesta, non solo il singolo messaggio a cui si applica la firma. Per questa funzionalità, il flag req consente a entrambi i firmatari di segnalare esplicitamente quale parte del contesto è usata come sorgente per il valore di un identificatore di componente. Le implementazioni devono garantire che solo il messaggio inteso sia referenziato per ogni componente; altrimenti un attaccante potrebbe tentare di sovvertire una firma manipolando un lato o l'altro.