Web服务响应是否需要安全签名？ [英] Do we need a security signature for the web service response?
问题描述
我已经创建了一个Web服务API，其架构使得服务器需要客户端对请求以及为其分配的密钥进行签名（多个请求之间的签名始终不同）。
服务器将客户端的签名与其自己的计算签名进行匹配。如果匹配，则服务器返回响应。
我想知道客户端是否应该检查来自服务器的响应，以查看是否来自同一应用程序
HTTP请求和HTTP响应之间是否可能发生任何攻击？
Web服务响应是否需要安全签名？
这要视情况而定。有几种类型的Web服务API。有些需要严格的安全性，而其他可能不需要。您可能有几种类型的API：
（1）完全打开的API。假设您有一个博客，其中发布了有关编写RESTful服务的信息。和客户。您可以根据其中一篇文章托管一个完整的REST服务，以便人们试用。您不在乎谁调用您的服务，该服务会返回一些虚拟数据等。这只是一个演示，一个玩具，这里没有安全保护，没有请求签名，nada。只是普通的HTTP调用。
（2）具有API密钥的服务。假设您有一个Web服务，并且想知道谁在调用它。此类服务需要预先注册，每个想要致电您的服务的客户都需要先注册并获取密钥。请注意，注册与认证或授权无关，您只想知道谁在使用您的API（例如，他们在哪个业务部门中工作，他们有多少客户，他们为什么使用您的API等），以便您以后进行对您自己进行一些分析，然后根据您获得的数据做出一些（可能是营销）决策。
此API密钥没有什么秘密。它只是某种UUID，是区分通话的最基本方法。同样，这仅涉及带有密钥作为附加请求参数的纯HTTP调用。
（3）服务，带有API密钥和秘密密钥。与数字（2）相似，但是您必须绝对确保调用来自提供一些API密钥的客户端。您之所以需要这样做，是因为您可能想向客户收取多少服务使用费用。您要确保呼叫实际上是来自该客户的电话，而不是一个有意向的客户，它可能想多收客户的账单。
因此，客户端使用它的密钥进行识别，并使用密钥对请求进行签名，以实际证明其身份。同样，这可以是普通的HTTP调用，将密钥和签名作为附加请求参数。
（4）数据防篡改 Web服务。对于上述数字（1），（2）和（3）没有考虑任何消息安全性问题，因为大多数API都不需要它。交换的内容不是机密信息，也不是必须保护的所有内容。但是有时候，尽管数据不是保密的，但您仍需要确保在传输过程中数据没有被篡改。
假设您是一家生产某些产品的商店的所有者，并且您想在某些合作伙伴网站上做广告。您使用产品详细信息公开服务，而您的合作伙伴仅使用此数据在其网站上显示您的产品详细信息。每个人都知道您正在制造什么产品，因此您不需要隐藏它们，但是您对竞争试图毁灭您感到偏执，因此您要避免它们拦截
的请求并将价格中的所有价格乘以10您的结果的响应只是吓跑了潜在的买家。
上面的数字（3）尽管使用签名部分作为证明呼叫者身份的方式，但也可以确保该请求未被篡改（如果签名不匹配，服务器将拒绝该请求）。因此，如果您需要确保原始回复，也可以在回复上签名。
为此，该服务可以为客户端提供一个API密钥和两个秘密密钥。客户端使用一个秘密密钥来签名他们的请求，而客户端使用第二个秘密密钥来验证响应的签名（为服务器使用唯一的秘密密钥并不是那么安全，因此服务器会发出服务器
但这有一个弱点：您需要信任您的合作伙伴，他们确实会在显示信息之前验证响应签名。该网站，而不只是直截了当地显示它。
正如@SilverlightFox所提到的，这证明了响应的有效性。数据没有经过处理，因为已加密。客户端不需要采取额外的步骤来验证响应签名，因为该验证已经在较低（传输）级别进行了。
（5）安全的服务。现在，我们到达了实际上是对数据保密的最后一种服务。这些服务必须使用HTTPS。 HTTPS确保数据保持机密，不会在传输过程中变温，标识服务器，并且如果使用了客户端证书，还可以标识客户端。
因此，最后，这取决于您所提供的服务类型。
I have created a web service API and it's architecture is such that the server requires a client to sign the request along with a secret key assigned to it (signature is always different between multiple requests).
Server matches the client's signature with its own computed signature. If they are a match then the server returns the response.
I am wondering if a client should check the response coming back from the server to see if it's from the same application to which the request was made.
Is any kind of attack possible between HTTP request and HTTP response?
Do we need a security signature for the web service response?
It depends. There are a few types of web service APIs out there. Some need strict security other might not. You could have a few types of APIs:
(1) completely opened API. Say you have a blog where you post about writing RESTful services and clients. You host a complete working REST service based on one of your posts so that people give it a spin. You don't care who calls your service, the service returns some dummy data etc. It's just a demo, a toy, no security here, no request signing, nada. It's just plain HTTP calls.
(2) service with an API key. Say you have a web service and you want to know who calls it. This kind of service needs a pre-registration and each client who wants to call your service needs to register and obtain a key first. Do note that the registration is not about authentication or authorization, you just want to know who's using your API (e.g. what business sector they operate in, how many clients they have, why are they using your API for etc) so that you later make some analysis of your own and take some (marketing maybe) decisions of some sort later on based on the data you get back.
There is nothing secret about this API key. It's just an UUID of some sort, the most basic way of differentiating between calls. This again involves only plain HTTP calls with the key as an additional request parameter.
(3) service with an API key and a secret key. This is similar to number (2) but you need to absolutely make sure that the calls are coming from the client that presents some API key. You need this because you probably want to bill the client for how much they have used your service. You want to make sure the calls actually come from that client and not someone ill intentioned that maybe wants to overcharge the client's bill.
So the client uses it's key for identification and a signature of the request with the secret key to actually vouch for it's identity. This again can be plain HTTP calls with the key and signature as additional request parameters.
(4) data "tampered-safe" web services. For numbers (1), (2) and (3) above I haven't considered any message security issues because most APIs don't need it. What's exchanged isn't confidential and not all that important to protect. But sometimes although the data isn't confidential you need to make sure it wasn't tampered with during transit.
Say you are the owner of a shop that builds some product and you want to advertise your product on some partner web sites. You expose a service with the product details and your partners just use this data to display your product details on their sites. Everybody knows what products you are building so you don't need to hide that, but you are paranoid about your competition trying to ruin you so you want to avoid them intercepting the request and multiplying by 10 all your prices in the responses of your result just to scare potential buyers away.
Number (3) above, although uses the signing part as a way to prove the identity of the caller, also assures the request was not tampered with (server will reject the request if the signature does not match). So if you need to assure an original response you can also sign the response.
For this, the service can provide the client with an API key and two secret keys. One secret key is used by the client to sign their requests while the second secret key is used by the client to verify the signature of the response (using an unique secret key for the server isn't all that safe so the server emits a server secret key specific to each client).
But this has a weak point: you would need to trust your partners that they will indeed validate the response signature before displaying the information on the site and not just bluntly display it. Paranoid as you are you want to protect against this and for this you need HTTPS.
As @SilverlightFox mentioned this proves the validity of the response. The data was not tempered with because it's encrypted. The client does not need to have an extra step to verify the response signature because that verification is already done at a lower (transport) level.
(5) secure services. And now we reach the last type of service where the data is actually confidential. HTTPS is a must for these services. HTTPS ensures the data remains confidential, that it isn't tempered in transit, identifies the server and can also identity the client if client side certificates are used.
So, in conclusion, it depends on what type of service you have.
这篇关于Web服务响应是否需要安全签名？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
