假设您有一个使用 SOAP 连接您的后端的移动应用程序(Windows Phone 或 Android)。
为了简单起见，假设我们有一个用 C# 实现的 Web 服务。服务器公开以下方法:
[WebMethod]
public string SayHallo() { return "Hallo Client"; }
从服务器的角度来看，您无法判断调用者是您的移动应用程序，还是试图调试您的网络服务的开发人员，还是试图逆向工程/利用您的后端的黑客。
如何确定 Web 服务调用的来源是应用程序？因为任何拥有 WSDL 的人都可以调用 WS。
我知道我可以对 Web 服务实现一些标准的安全措施，例如:
- 在服务器上实现 HTTPS，以便消息加密传输并降低窃听的危险。
- 使用摘要/哈希算法在客户端对请求进行签名，在服务器中验证签名并拒绝未正确签名的消息。
- 在 HTTP 请求中写入自定义 header 。无论如何，标题都可以模拟。
但是，任何经验丰富的黑客或知道签名算法的开发人员仍然可以生成签名良好、格式化良好的消息。或者一个非常优秀的黑客可以拆解应用程序并获得我的“绝密”通信协议(protocol)的隐藏知识。
有什么想法可以让 SayHallo() 方法只回答来 self 的移动应用程序的请求吗？
我们在移动应用程序的上下文中运行，通过硬件访问，可以利用硬件功能完成一些事情。
如果有人想知道，我正在考虑如何让移动应用程序对银行等敏感应用程序足够安全。
感谢您的想法。
最佳答案
您所描述的是双向身份验证。它只能通过在通信双方存储签名的公钥(证书)来完成。这意味着每个应用程序都需要使用您的服务器公钥对您的服务器进行身份验证，并且服务器需要对您的应用程序的每个实例进行身份验证。应用程序的公钥将需要在部署时与应用程序的每个实例一起生成并存储在服务器上。将此视为 2 路 HTTPS，通常唯一需要完成的身份验证是一个方向，浏览器使用受信任的签名 key 对服务器进行身份验证。在您的情况下，这需要在双方都完成。通常你会有一个像 VeriSign 这样的服务签署一个公钥的每个实例，这对于一个应用程序的多个部署来说可能会变得非常昂贵。在您的情况下，您可以使用诸如 OPENSSL 之类的东西创建一个内部签名应用程序，以便在每次分发您的应用程序时对其进行签名。这并不意味着有人仍然无法破解您的代码并在应用程序端提取签名 key 。一般来说，任何代码都可能被黑客入侵，问题只是在他们放弃之前你能做到多难？如果您要走自定义硬件路线，那么加密芯片和 TMP 之类的东西可以充当 keystore ，使人们更难访问设备上的私钥。
快速谷歌搜索出现以下内容:
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
如果您正在考虑使用奖励积分，并且真的担心有人从外部玩弄系统，那么更好的解决方案是让每个人都创建一个安全存储在服务器上的帐户，并将他们的积分保存并在那里计算.这集中了所有数据，并允许您完全控制它，而不必担心恶意应用程序报告不存在的点。 (这就是银行的运作方式)
关于android - 如何验证 Web 服务调用的来源，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14023348/