Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I have came across a REST API for some commercial software, that checks authentication by requiring HMAC on concatenation of
https://domain.tld and the first question mark)This HMAC then is passed in a request header.
What does this scheme protect against by including the path?
It drastically limits replay attacks, in the unlikely event that an attacker gets ahold of the request. For example, suppose a legit user sends the following request:
DELETE /basically/innocuous/trivia HTTP/1.1
Authorization: blahblahblah
...
An attacker gets access to this message somehow (maybe they control a TLS-terminating load balancer or something), before the timeout expires. The attacker now has a short-lived HMAC that they can replay, but only for DELETE requests. However, there's nothing stopping them from submitting the following request:
DELETE /totally/critical/data HTTP/1.1
Authorization: blahblahblah
...
Because the path isn't part of the HMAC, changing the path doesn't invalidate the request. Because everything else is the same (method, time [within margin], body [or lack thereof]), the request is accepted and executes with the original user's permissions!
If you instead require that the path also be part of the HMAC, all that an attacker can do is delete the same item over again. This might be awkward but is probably OK (after all, unless it was created / uploaded again, there's nothing delete now). Even if they are able to do some harm by repeatedly deleting that item, they can't delete everything else too (or at least everything they can submit requests for prior to the HMAC timestamp expiring).
Note that this scheme is still missing some things! You're not signing most of the headers, and some of those could change the server behavior. You're not signing the query string, and that could absolutely change behavior.
Take a look at AWS SigV4 for an idea of the full list of things that they consider important to include in the HMAC signature (either because they're part of the request itself, or because they're part of the signing key). It's possible SigV4 is a little over-engineered - I think some of the "layers" of HMACs might be based on older signature schemes, so there's some redundancy there which might not be needed - but it does no harm (aside from making implementation more complicated as a user, and that's what libraries are for).
