7.2.8. Contenuto del messaggio (Message Content)

7.2.8. Contenuto del messaggio (Message Content)

Da sola, questa specifica non fornisce copertura per il contenuto di un messaggio HTTP sotto la firma, né in una richiesta né in una risposta. Tuttavia, [DIGEST] definisce un insieme di campi che consentono di rappresentare in un campo un digest crittografico del contenuto. Una volta creato questo campo, può essere incluso come qualsiasi altro campo definito nella Sezione 2.1.

Ad esempio, nel seguente messaggio di risposta:

HTTP/1.1 200 OK Content-Type: application/json

{"hello": "world"}

Il digest del contenuto può essere aggiunto al campo Content-Digest come segue:

NOTA: a capo con '' secondo RFC 8792

HTTP/1.1 200 OK Content-Type: application/json Content-Digest:
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

{"hello": "world"}

Questo campo può essere incluso in una base della firma come qualsiasi altro campo insieme ai parametri di firma di base:

"@status": 200 "content-digest":
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=: "@signature-input": ("@status" "content-digest")

Da qui, il processo di firma procede come al solito.

In fase di verifica, è importante che il verificatore convalidi non solo la firma ma anche il valore del campo Content-Digest stesso rispetto al contenuto effettivamente ricevuto. A meno che il verificatore non esegua questo passaggio, sarebbe possibile per un attaccante sostituire il contenuto del messaggio ma lasciare inalterato il valore del campo Content-Digest per superare la firma. Poiché solo il valore del campo è coperto direttamente dalla firma, controllare solo la firma non è protezione sufficiente contro un tale attacco di sostituzione.

Come discusso in [DIGEST], il valore del campo Content-Digest dipende dalla content encoding del messaggio. Se un intermediario cambia la content encoding, il valore Content-Digest risultante cambierebbe. Ciò a sua volta invaliderebbe la firma. Qualsiasi intermediario che esegue tale azione dovrebbe applicare una nuova firma con il valore del campo Content-Digest aggiornato, analogamente al caso d'uso del reverse proxy discusso nella Sezione 4.3.

Le applicazioni che usano il parametro req (Sezione 2.4) devono anche essere consapevoli delle limitazioni di questa funzionalità. In particolare, se un client non include qualcosa come un campo Content-Digest nella richiesta, il server non è in grado di includere una firma che copra il contenuto della richiesta.