如何确保HTTP上载来自真实的可执行文件

我们正在编写一个本机windows应用程序（MFC），它将向我们的web应用程序上载一些数据。Windows应用程序将允许用户登录，之后它将定期向我们的web应用程序上载一些数据。上传将通过简单的HTTP POST上传到我们的web应用程序。我担心的是，我们如何确保上传的内容实际上来自我们的应用程序，而不是curl之类的东西。我想我们正在研究某种公钥/私钥加密。但我不确定我们是否可以在win应用程序的可执行文件中嵌入一个公钥，然后使用它。或者，在我们的应用程序之外提取和使用公钥会不会太容易

---

无论如何，我们正在构建双方（客户机和服务器），所以几乎任何东西都是一个选项，但它必须通过HTTP（S）工作。但是，我们不控制win（客户端）应用程序的执行环境，而且在他/她的系统上运行应用程序的用户是唯一一个通过玩该系统获得某些东西的用户。

既然您控制客户端，您还可以将密钥嵌入应用程序中，并确保用户没有对应用程序映像的读取权限-您需要将逻辑分为两层-一层是用户运行的，另一层是通过HTTP（S）连接到服务的-因为用户将始终具有对正在运行的应用程序的读取权限

---

如果我理解正确，数据会在用户登录后自动发送-这听起来似乎只需要服务部分。

最终，当应用程序在您不拥有的机器上运行时，无法通过这种方式证明其身份。你可以嵌入密钥，玩散列和校验和，但最终，任何依赖于别人机器上运行的代码的东西都可能被伪造。钥匙可以提取，代码可以逆向工程——这一切都是通过隐蔽性实现的安全

---

将您的时间花在验证和数据清理上，如果您真的想保护某些东西，请使用客户端证书保护最终用户。其他任何事情都只是浪费时间和错误的安全感。

您最好将HTTPS与客户端证书一起使用。大概是与的接口

但我不确定我们是否可以在win应用程序的可执行文件中嵌入一个公钥，然后使用它

如果客户端要向服务器标识自己，则必须是嵌入的私钥

或者在我们的应用程序之外提取和使用会不会太容易

如果您不控制客户端应用程序的执行环境，那么您的应用程序所能做的任何事情都可以由控制该环境的攻击者进行分析、自动化和复制

---

如果必须，您可以在通信过程中放置模糊层，但您永远无法解决问题。多年来，多人游戏一直在尝试这样做，以打击作弊行为，但最终这只是一场模糊的军备竞赛，永远无法获胜。暴雪拥有的资源比你多得多，他们也无法管理。

一旦你的应用程序发布，你就无法控制二进制文件。如果所有签名和加密逻辑都驻留在可执行文件中，则可以提取。当有足够的动机这样做时，聪明的程序员会找出代码并构建可互操作的系统。这就是为什么DRM不起作用

例如，将密钥绑定到PC的MAC地址的复杂系统肯定会失败

---

不要信任特定的可执行文件或系统，但要信任您的用户。将受密码短语保护的私钥文件委托给他们，并向他们解释该密钥如何将他们识别为您服务内容的提交者。

favorite:我有一些想法，但我不是真正的加密人。希望有一个真正的人会路过，给出一个明确的答案。顺便说一句，如果你提出了一个策略，然后要求社区对其进行评论，你可能会得到更好的答案。记住永远不要相信你的用户，他们是欺骗和恶意的。无论谁否决了这一点，请提供一个理由。原始海报明确表示，他控制调用环境，即客户端，如果是，我的回答是有效的。我不是DV，但他还表示，他知道攻击者可以提取密钥，这意味着他们实际上无法控制执行环境。我想他们的意思是说他们只是在构建客户端和服务器。我最初不清楚，并更新了这个问题，以反映我们并没有实际控制客户端应用程序的执行环境。根据这里的答案，我意识到没有真正的“解决方案”解决这个问题，因为用户是唯一一个通过游戏系统获得东西的人，因此，我不认为带有密码短语的私钥在这种情况下有帮助？如果用户认为私自签署其他人的及时上传文件不会造成任何损害，或者如果将他们的密钥集成到另一个应用程序中对他们有利，那么你就无能为力了。我现在意识到你是对的，这只是一种虚假的安全感。但是，如果用户实际上是试图通过上传虚假/捏造的数据来玩系统游戏的人，那么客户端证书在这里会有帮助吗？只有这样，你才能非常肯定地知道是谁在做这件事，并且如果他们破坏了系统，你可以撤销他们的证书（假设您在发出CRLs/OCSP的CA和验证服务器上正确设置了CRLs/OCSP）。没错，控制客户端的人可以做任何事情，包括绕过您的所有安全措施。这可能采取修改内存中程序变量的形式，这很难防范（实际上不可能），包括可能在VM中运行它，以及从VM外部修改内存（无法检测到进行修改的应用程序）。OP的最佳选择是尝试验证上载，以便即使上载垃圾也不会发生任何错误