7.4.3. Message Component Source and Context

7.4.3. Message Component Source and Context

The signature context for deriving message component values includes the target HTTP message itself, any associated messages (such as the request that triggered a response), and additional information that the signer or verifier has access to. Both signers and verifiers need to carefully consider the source of all information when creating component values for the signature base and take care not to take information from untrusted sources. Otherwise, an attacker could leverage such a loosely defined message context to inject their own values into the signature base string, overriding or corrupting the intended values.

For example, in most situations, the target URI of the message is as defined in [HTTP], Section 7.1. However, let's say that there is an application that requires signing of the @authority of the incoming request, but the application doing the processing is behind a reverse proxy. Such an application would expect a change in the @authority value, and it could be configured to know the external target URI as seen by the client on the other side of the proxy. This application would use this configured value as its target URI for the purposes of deriving message component values such as @authority instead of using the target URI of the incoming message.

This approach is not without problems, as a misconfigured system could accept signed requests intended for different components in the system. For this scenario, an intermediary could instead add its own signature to be verified by the application directly, as demonstrated in Section 4.3. This alternative approach requires a more active intermediary but relies less on the target application knowing external configuration values.

As another example, Section 2.4 defines a method for signing response messages and also including portions of the request message that triggered the response. In this case, the context for component value calculation is the combination of the response and request messages, not just the single message to which the signature is applied. For this feature, the req flag allows both signers to explicitly signal which part of the context is being sourced for a component identifier's value. Implementations need to ensure that only the intended message is being referred to for each component; otherwise, an attacker could attempt to subvert a signature by manipulating one side or the other.