1

我一直在研究为我们的 REST Web 服务使用正确的安全机制。我正在阅读有关 HTTP 签名的文档 -> https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12。

根据此文档，选择、散列和数字签名的一些 HTTP 标头。此签名字符串在 HTTP 标头中更新。服务提供者将重新创建散列（基于接收到的 HTTP 标头）并验证签名字符串以验证客户端。这也反过来证明消息没有被篡改。

某些有权访问网络的黑客是否有可能只更改 HTTP 正文而不更改作为签名一部分的标头属性。如果是，那么服务提供商收到的消息不是客户端想要的消息，不是吗？那么，这种对 HTTP 请求进行签名的方式如何保证消息的完整性呢？

4

3 回答 3

1

您可以在标题中包含正文的摘要（哈希）。因此，如果 body 发生变化，Digest 也会发生变化，并且不会与 body 的 Digest 匹配。

快速浏览您所指向的规范文档：在第 10 页的底部，如下所示：

POST /foo HTTP/1.1
主机：example.org
日期：2014 年 6 月 7 日星期二 20:51:35 GMT
内容类型：application/json
摘要：SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
内容长度：18

{“你好世界”}

请注意，Digest标头字段的使用符合 RFC 3230 [RFC3230] 的第 4.3.2 [12] 节，并且仅作为实现者如何在签名中包含有关消息正文的信息的演示。

于 2020-01-24T06:17:46.687 回答
1

某些有权访问网络的黑客是否有可能只更改 HTTP 正文而不更改作为签名一部分的标头属性。

是的。签名未涵盖的任何内容都可以在不被发现的情况下被更改——当然，假设攻击者也能够破坏其他完整性保护机制（TLS 也提供了这一点）。

如果是，那么服务提供商收到的消息不是客户端想要的消息，不是吗？

真的。只有一个更正。消息中受完整性保护的部分不能在未经检测的情况下被更改。因此，虽然整个信息可能是伪造的，但可能有一些部分仍然完好无损并与原始信息相匹配。

那么，这种对 HTTP 请求进行签名的方式如何保证消息的完整性呢？

它仅确保客户选择签名的部分的完整性。为了保证完整消息的完整性，您还需要检查headers已签名的 ，并确保它涵盖了您想要处理的所有内容。

如果您想了解有关签名方案和替代方案的更多信息，请查看我写的关于此的帖子：Web API 身份验证指南，签名方案。

于 2020-01-24T21:22:43.580 回答
-1

还有一种不同的机制也可以防止篡改，适用于标头和正文（以及其他所有内容）并且已经得到广泛支持：HTTPS

于 2020-01-24T07:09:56.740 回答