我一直在研究将正确的安全性机制用于REST Web服务。我正在浏览有关HTTP签名-> https://tools.ietf.org/html/draft-cavage-http-signatures-12的文档。
根据此文档，选择了一些HTTP标头，对其进行了哈希处理并进行了数字签名。该签名的字符串在HTTP标头中更新。服务提供者将重新创建哈希（基于收到的HTTP标头）并验证签名的字符串以验证客户端。这也反过来证明了该消息未被篡改。
某些可以访问网络的黑客可以仅更改HTTP正文而无需更改作为签名一部分的标头属性。如果是，则服务提供商收到的消息不是客户端想要的消息，不是吗？那么，这种签名HTTP请求的方式如何确保消息的完整性？
您可以在标题中包含正文的摘要（哈希）。因此，如果身体发生变化，摘要将发生变化，并且与身体的摘要不匹配。
快速浏览您所指向的规范文档：在第10页的底部，如下所示：
POST / foo HTTP / 1.1主持人：example.org日期：2014年6月7日，星期二20:51:35 GMT内容类型：application / json摘要：SHA-256 = X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE =内容长度：18
{“ hello”：“ world”}
请注意，
Digest标头字段的使用符合RFC 3230 [RFC3230]第4.3.2 [12]节的规定，仅作为实现者如何将有关消息正文的信息包括在文件中的示例。签名。
[还有一种不同的机制也可以防止篡改，可以与标头和正文（以及所有其他内容）一起使用，并且已经得到广泛支持：HTTPS
某些可以访问网络的黑客可以仅更改HTTP正文而无需更改作为签名一部分的标头属性。
是。签名未涵盖的任何内容都可以更改而无需检测-当然，假设攻击者也能够颠覆其他完整性保护机制（TLS也提供此功能）。
如果是，则服务提供者收到的消息不是客户端想要的消息，不是吗？
是。只有一个更正。如果没有检测，则无法更改受完整性保护的消息部分。因此，尽管整个邮件可能是伪造的，但仍有一些部分仍然完整无缺并与原始邮件相匹配。
因此，这种签名HTTP请求的方式如何确保消息的完整性？
它仅确保客户选择签名的部件的完整性。为了提供完整的消息完整性，您还需要检查已签名的headers，并确保它涵盖了您要处理的所有内容。
[如果您想了解有关签名方案和替代方案的更多信息，请参阅我撰写的与此相关的文章：Web API Authentication Guide, Signature Schemes。