验证 iOS 应用程序
我们有一个 iOS 应用程序，它与后端的各种 Web 服务交互。然而，后端想要验证发送给它的请求是否来自我们有效的 iOS 应用程序，而不是来自重放攻击或“中间人”攻击。我们最终会将所有调用更改为 https。但是，后端有什么方法可以验证请求是否来自我们的合法应用程序？我们正在考虑在每个请求中使用加密随机数，但它仍然容易受到“中间人”攻击。 iOS 应用程序和服务器之间是否可以使用任何证书交换？
We have an iOS app which interacts with various webservices at the backend. The backend however wants to validate that the request coming to it is from our valid iOS app and not from a replay attack or a "man in the middle" attack. We are eventually going to have all our calls changed to https. However, is there any way the backend can validate the request is coming from our legitimate app? We were thinking of using cryptographic nonce with every request, but it would still be prone to "man in the middle" attack. Is there any certificate exchange that can be used between the iOS app and the server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
TLS 和 SSL 支持使用证书的客户端身份验证。 NSStream可能支持客户端身份验证，但我无法找到一种方法来做到这一点，而不需要直接使用 OpenSSL 进行实际实现。
添加：
ASIHTTPRequest 支持客户端证书 自版本 1.8 以来，因此在实现它时没有大惊小怪。
TLS and SSL support client authentication using certificates. NSStream might support client side authentication, but I have not been able to find a way to do it without dropping down to using OpenSSL for the actual implementation.
Addition:
ASIHTTPRequest supports client certificates since version 1.8, so no fuss in implementing it.
使用私钥/公钥方案以便 iOS 应用程序可以对其发送的每个请求进行签名怎么样？
如果私钥/公钥方案听起来很可怕，那么通过使用 sha1、sha2 或其他加密哈希算法。这将非常容易实现（实现很容易实现）、快速，并且将确保更高的安全级别。
what about using a private/public key scheme so that the iOS app can sign every request it sends?
if private/public key scheme may sound scary, the same idea of "signing" your requests can be easily implemented by hashing your crypto nonce by using sha1, sha2 or other cryptographic hashing algorithms. this would be pretty easy to implement (implementation are readily available), fast, and would ensure a higher security level.
我建议使用 OAuth。它众所周知、易于理解并且非常安全，如果有人获得您的令牌，您可以通过应用程序更新发布新的令牌并撤销旧的令牌。
I would suggest to use OAuth. It well known and understood and pretty much secure, and in the case that someone gets your token, you can issue a new one with an app update and revoke the old one.
这是一个普遍的 http 问题，而不仅仅是 iOS 问题。事实上，这正是 https 旨在解决或至少缓解的问题。您可以对请求进行签名、使用 HMAC 对消息进行身份验证、使用摘要身份验证等，但只要您使用 http，就无法轻易检测到中间人攻击。花时间尽快转向 https。
This is a general http problem, not just an iOS issue. In fact, it's the very problem https is designed to solve, or at least mitigate. You can sign the request, use HMAC to authenticate the message, use digest authentication, and so on, but as long as you're using http, a man-in-the-middle attack cannot be easily detected. Spend your time moving to https as quickly as you can instead.
这个问题是不可能绝对解决的。您放入方案中的任何内容最终都可以通过越狱手机并在调试器中运行客户端来破坏。当然，这并不意味着您不能使用客户端证书等来欺骗您的客户端，而且您应该这样做。但是，如果金融交易的安全性取决于您的应用程序不可欺骗，那就糟糕了……
This problem is impossible to solve absolutely. Anything you put into your scheme can be ultimately broken by jailbreaking the phone and running the client in a debugger. Of course, that doesn't mean you can't make it more difficult to spoof your client using client certificates and whatnot, and you should. But if for example the security of financial transactions depend on your app not being spoofable, that would be bad...