CODEWITHSUNDEEP
restweb-servicessecuritydigital-signaturehttp-signature
JayKrish
JayKrish

Reputation: 947

REST based web services security based on HTTP signatures

I have been doing some research on using the right security mechanism for our REST web service. I was going through the documentation on HTTP Signatures -> https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12.

Based on this documentation some of HTTP headers are selected, hashed and digitally signed. This signed string is updated in the HTTP header. The service provider will recreate the hash (based on received HTTP headers) and verify the signed string to authenticate the client. This also in turn proves the message is not tampered with.

Is it possible for some hacker who has access to the network to just change the HTTP body without changing the header attributes that are part of the signature. If yes, then the message received by service provider is not the one intended by the client is it not? So, how does this way of signing the HTTP request ensure message integrity?

Upvotes: 1

Views: 1576

Answers (3)

Daniel Szpisjak
Daniel Szpisjak

Reputation: 426

Is it possible for some hacker who has access to the network to just change the HTTP body without changing the header attributes that are part of the signature.

Yes. Anything that isn't covered by the signature can be altered without detection — given, of course, that the attacker is also able to subvert other integrity protection mechanisms (TLS also provides this).

If yes, then the message received by service provider is not the one intended by the client is it not?

True. There is just one correction. The parts of the message that are integrity protected cannot be altered without detection. So while the whole message may be forged, there may be some parts that are still intact and match the original.

So, how does this way of signing the HTTP request ensure message integrity?

It only ensures integrity for the parts that the client chooses to sign. To provide integrity for the full message, you also need to check the headers, which were signed and make sure it covers everything you would like to process.

If you would like to learn more about signature schemes and alternatives, check out a post I wrote about precisely this: Web API Authentication Guide, Signature Schemes.

Upvotes: 1

Evert
Evert

Reputation: 99728

There's a different mechanism that also prevents tampering, works with headers and body (and everything else) and is already widely supported: HTTPS

Upvotes: -1

Bharat Vasant
Bharat Vasant

Reputation: 935

You may include Digest (Hash) of the body in the header. Thus, if body changes, Digest will change and will not match with the Digest of the body.

A Quick glance over the specification document you are pointing to: At the bottom of Page 10, read as below:

POST /foo HTTP/1.1
Host: example.org
Date: Tue, 07 Jun 2014 20:51:35 GMT
Content-Type: application/json
Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Content-Length: 18

{"hello": "world"}

Note that the use of the Digest header field is per RFC 3230 [RFC3230], Section 4.3.2 [12] and is included merely as a demonstration of how an implementer could include information about the body of the message in the signature.

Upvotes: 1

Related Questions