Request Protection
Response Protection
Response Swaping Protection
Replay Attack Protection
Cache Compatibility
Allow Benign Message Modification
AWS [Ama19b] # #
Google [Goo17] # #
HP [Hew14] # #
Microsoft [Mic17] # #
SHREQ [Run19] # #
OAuth1 [Har12] # #
OAuth Mac Tokens [RMT14] # #
Signing an HTTP Request for OAuth [RBT16] # # #
Lo Iacono et al. [LNG19] # #
Cavage et al. [CS19] # #
Serme et al. [Ser+12] # # #
SRI [Dev+16] # G# # #
Stickler [LCB16] # G# # G#
Table 7.1: Analysis of the related work in HTTP signature schemes
The goal of HTTP signature schemes is to provide end-to-end integrity and authenticity by digitally signing the HTTP messages or certain parts of them. Although the available schemes are different from each other, they still follow a common procedure when signing and respectively verifying HTTP messages (see Figure7.3).
The signing procedure starts with processing the HTTP message, which is to be signed. First, a string representation is generated from the message by concatenating a time-variant parameter (TVP), the entries of the message headers, and the hash of the message body. This constructed string is then signed with a signature generation key. After that, theSignatureheader is built
TVP + Header 1
… + Header n + Hash of Body
Signature Value, TVP,
Key ID Header 1
… Header n Signature Header
Body Process
Message
Build String to be signed
Generate Signature Signature Value
Generate Signature Header
Embed Signature Header
Process Message
Extract Signature Header
Build String to be verified
Verify Signature true / false TVP
+ Header 1
… + Header n + Hash of Body Signature Value,
TVP, Key ID
Signature Generation Signature Verification
Header 1
… Header n
Body
Header 1
… Header n Signature Header
Body
Figure 7.3: Process diagram visualizing the general steps all HTTP signature schemes adopt when signing and verifying HTTP messages
by concatenating the string representation of the key ID, the TVP and the signature value. This new header is finally added to the HTTP message headers as emphasized in Figure7.3.
Accordingly, the verification procedure starts with processing the signed HTTP message. First, theSignatureheader is extracted from the message and the contained items are retrieved from it. In the following step, the string to be verified is constructed by concatenating the string representations of the TVP, the entries of the message headers, and the hash of the body. The last step verifies the signature and checks the validity of the TVP in order to detect replay attacks.
As said before, the available HTTP signature schemes follow this general process with slight deviations. Amazon Web Services (AWS), Google, Hewlett Packard (HP), and Microsoft use self-developed HTTP signature schemes for users to authenticate to their cloud storage services [Ama19b; Goo17;Mic17; Hew14]. Their schemes do make use of a TVP to avoid replay attacks, but they do neither sign the response nor all request headers. Instead, they define a set of request headers that is considered security-relevant, including the HTTP method, the URL and theHostheader. These headers have to be non-empty and present exactly once for the message to be valid. The computed signature value and the signature-related metadata are then placed in theAuthorizationheader, which is finally added to the request.
Signed HTTP Requests (SHREQ) [Run19] is very similar to the industry-driven approaches, as it provides end-to-end integrity for request messages only. It signs a subset of request headers and adds a TVP to the signature to avoid replay attacks. The signature value and the corresponding metadata are either included in the body or in case of requests without a body in the URL.
The first version of the authorization frameworkOAuth[Har12] as well as theOAuth 2.0draft extensionsOAuth Mac Tokens[RMT14] andSigning an HTTP Request for OAuth[RBT16] also sign requests only following a predefined list of to be protected headers. While OAuth 1.0 has been established as an official web standard, the both draft specifications have not been updated since 2014 and 2017.
Cavage et al. [CS19], Lo Iacono et al. [LNG19], and Serme et al. [Ser+12] proposed HTTP signature schemes that protect the request as well as the response message. The scheme by Serme et al. includes a TVP in the signature to detect replay attacks and embeds the signature value as well as the signature metadata in signature headers starting withX-JAG-*. However, it does not define a list of to be signed headers. Instead, all headers are considered in the signature and verification procedure. This may impair the signature’s validity when an intermediate system modifies or adds a protected header. Caches usually add a header to traversing request messages to validate the response freshness (see Figure7.2). If this happens, the string to be signed built by the client and the string to be verified crafted by the origin server are different. This issue hampers web applications to use the security mechanism of Serme et al. in conjunction with caches. Cavage et al. and Lo Iacono et al. instead provide a list of security-relevant message
headers. Headers not part of the list can be modified and added by intermedaries. Both signature schemes also require to integrate a TVP to avoid replay attacks. The resulting signature value and the corresponding metadata is inserted in the introducedSignatureheader. A major issue that affects all three approaches is a missing distinction between a replay attack and benign replayed message. A reused cached message contains the same signature value and TVP as the original one. Clients receiving a reused signed response message twice, may assess this signed replication as a replay attack, which is the case for all three HTTP signature schemes as they are not compatible with caches. As the current state does not provide a solution for this issue, web applications which consider to use these security mechanisms are forced to disable caching. The other HTTP signature schemes which only protect the request message can be used in conjunction with caches. Here, the client does not have to deal with the distinction between replay attacks and reused signed response messages from a benign cache, as there is no end-to-end security and replay attack protection for the response message at all. Another drawback of all three HTTP signature schemes is the missing protection against attack vectors which swap signed responses.
Many web applications use Subresource Integrity (SRI) [Dev+16] for providing end-to-end integrity of static files. SRI is used in conjunction with CDNs to distribute public resources. The integrity of the content is ensured by a message body hash generated by the service provider.
The hash value is included in an attribute of the corresponding HTML tag (e.g. <script ...
integrity=’sha384-...’>). The web browser verifies the integrity by comparing the hash value in the HTML attribute with the self-calculated hash value. This hash value only ensures the integrity of the response message body. Neither the request nor any message header is protected by SRI. A compromised or malicious cache can still replace the hash value with a hash value of a malicious content. Web browsers cannot detect such a man-in-the-middle attack, as SRI does not contain any mechanism to verify the authenticity.
Stickler [LCB16] is another end-to-end integrity protection scheme for cacheable static Web assets. The goal of Stickler is to ensure end-to-end integrity in Web-based application without the need to trust the cache for integrity. When a client visits a Stickler-protected website, the origin server returns an HTML page including a bootloader script. This script contains a public key, a script for retrieving and verifying the protected assets and the location of a manifest file.
The integrity and authenticity of the bootloader script is ensured by a TLS connection. The bootloader starts with invoking the manifest file containing a manifest signature. If the signature is valid, the bootloader retrieves the website’s assets based on a list included in the manifest.
Each asset in this list contains the asset’s URL, the corresponding hash or signature value and optionally an expiration date in order to prevent caches from serving stale or outdated content.
Since the integrity and authenticity of the manifest is ensured by a signature, the client can verify the integrity and authenticity of assets by comparing the assets’ hash or signature value. A shortcoming of Stickler is that it does not provide a replay attack protection for the manifest file, as it only contains a signature without an expiration date. A malicious cache is henceforth able to replace the current manifest file with an outdated one. Another major drawback of Stickler is the exclusive protection of the response body. The response headers remain unprotected.
Available HTTP attacks have shown, however, that the manipulation of the response header can have severe consequences [Kle04;LNG19].
A summary of this related work review is given in Table 7.1. It gets apparent that there is a lack of comprehensive protection means for HTTP messages that are cache-enabled.