我创建了一个Web服务API，它的体系结构使得服务器需要客户端对请求进行签名以及分配给它的密钥（签名在多个请求之间总是不同）。
服务器将客户端的签名与其自己的计算签名进行匹配。如果它们匹配，则服务器返回响应。
我想知道客户端是否应检查从服务器返回的响应，以查看它是否来自发出请求的同一应用程序。
HTTP请求和HTTP响应之间是否存在任何类型的攻击？
答案 0 :(得分：10)
我们是否需要Web服务响应的安全签名？
这取决于。有几种类型的Web服务API。有些人可能需要严格的安全保障。您可以使用几种类型的API：
（1）完全打开API。假设您有一个博客，您发布有关编写RESTful服务和客户端的文章。您可以根据自己的一个帖子托管一个完整的REST服务，以便人们可以自行调整。你不关心谁叫你的服务，服务返回一些虚拟数据等。它只是一个演示，一个玩具，这里没有安全，没有请求签名，虚无...它只是普通的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确保数据保密，在传输过程中不进行调整，识别服务器，如果使用客户端证书，还可以识别客户端。
所以，总结，这取决于您拥有的服务类型。
答案 1 :(得分：2)
请求HTTPS以确保回复的有效性。
这将确保您的数据不易受MITM attack攻击。滚动您自己未经测试的加密/散列方法是打开应用程序进行攻击的可靠方法，因此您应该使用TLS / SSL，这意味着您应该通过HTTPS连接到您的Web服务API。 TLS是经过验证的安全方式，可确保响应来自请求的应用程序。