我创建了一个 Web 服务 API，它的架构是这样的：服务器需要客户端签署请求以及分配给它的密钥（多个请求之间的签名总是不同的）。
服务器将客户端的签名与其自己的计算签名相匹配。如果它们匹配，则服务器返回响应。
我想知道客户端是否应该检查从服务器返回的响应，以查看它是否来自发出请求的同一应用程序。
HTTP 请求和 HTTP 响应之间是否可能发生任何类型的攻击？
【问题讨论】：
标签： web-services security rest digital-signature
我们是否需要 Web 服务响应的安全签名？
这取决于。有几种类型的 Web 服务 API。有些需要严格的安全性，有些则可能不需要。您可以拥有几种类型的 API：
(1) 完全开放的 API。 假设您有一个博客，在其中发布了有关编写 RESTful 服务和客户端的内容。您根据您的一篇文章托管一个完整的工作 REST 服务，以便人们对其进行旋转。您不在乎谁调用您的服务，该服务返回一些虚拟数据等。这只是一个演示，一个玩具，这里没有安全性，没有请求签名，nada。这只是简单的 HTTP 调用。
(2) 带有 API 密钥的服务。假设您有一个 Web 服务，并且您想知道是谁调用它。这种服务需要预先注册，每个想要调用您的服务的客户端都需要先注册并获取密钥。请注意，注册与身份验证或授权无关，您只想知道谁在使用您的 API（例如，他们在哪个业务部门经营，他们有多少客户，他们为什么使用您的 API 等），以便您以后制作对您自己进行一些分析，然后根据您返回的数据做出某种（可能是营销）决策。
这个 API 密钥没有什么秘密。它只是某种 UUID，是区分调用的最基本方法。这同样只涉及使用密钥作为附加请求参数的普通 HTTP 调用。
(3) 具有 API 密钥和密钥的服务。 这与数字 (2) 类似，但您需要绝对确保调用来自提供某些 API 的客户端钥匙。您需要这个，因为您可能想要向客户收取他们使用您的服务的费用。您要确保电话确实来自该客户，而不是恶意可能想要多收客户账单的人。
因此，客户端使用它的密钥进行识别，并使用密钥对请求进行签名来实际证明它的身份。这又可以是普通的 HTTP 调用，其密钥和签名作为附加请求参数。
(4) 数据“防篡改”网络服务。 对于上面的数字 (1)、(2) 和 (3)，我没有考虑任何消息安全问题，因为大多数 API 都没有不需要它。交换的内容不是机密的，保护起来也不是那么重要。但有时虽然数据不是机密的，但您需要确保它在传输过程中没有被篡改。
假设您是一家生产某种产品的商店的所有者，并且您想在某些合作伙伴网站上宣传您的产品。您使用产品详细信息公开服务，而您的合作伙伴只需使用此数据在他们的网站上显示您的产品详细信息。每个人都知道你在制造什么产品，所以你不需要隐瞒，但你偏执于你的竞争对手试图毁掉你，所以你想避免他们拦截 在您的结果响应中请求并乘以 10 您的所有价格，只是为了吓跑潜在买家。
上面的数字（3）虽然使用签名部分作为证明调用者身份的一种方式，但也保证了请求没有被篡改（如果签名不匹配，服务器将拒绝请求）。因此，如果您需要确保原始回复，您也可以在回复上签名。
为此，服务可以为客户端提供一个 API 密钥和两个密钥。客户端使用一个密钥来签署他们的请求，而客户端使用第二个密钥来验证响应的签名（使用服务器的唯一密钥并不是那么安全，因此服务器发出一个服务器特定于每个客户端的密钥）。
但这有一个弱点：您需要相信您的合作伙伴，他们确实会在网站上显示信息之前验证响应签名，而不仅仅是直截了当地显示它。偏执狂，你想防止这种情况发生，为此你需要 HTTPS。
正如@SilverlightFox 提到的，这证明了响应的有效性。数据没有经过处理，因为它是加密的。客户端不需要额外的步骤来验证响应签名，因为该验证已经在较低（传输）级别完成。
(5) 安全服务。 现在我们达到了数据实际上是机密的最后一种服务类型。这些服务必须使用 HTTPS。 HTTPS 确保数据保持机密，在传输过程中不会被篡改，识别服务器，如果使用客户端证书，还可以识别客户端。
所以，总之，这取决于您拥有的服务类型。
【讨论】：
通过HTTPS发起请求，保证响应的有效性。
这将确保您的数据不会受到MITM attack 的攻击。滚动您自己的未经测试的加密/散列方法是打开您的应用程序以进行攻击的可靠方法，因此您应该使用 TLS/SSL，这意味着您应该通过 HTTPS 连接到您的 Web 服务 API。 TLS 是经过验证且安全的方法，可确保响应来自发出请求的应用程序。
【讨论】：