我需要应用程序 1 在应用程序 2 上进行 POST，但在应用程序 2 上我需要确保 POST 来自应用程序 1。

出于本文的目的，我将应用程序 1 称为客户端，应用程序 2 称为服务器。

让我们从：

我最担心的是中间人攻击。

确保客户端与服务器建立连接时，客户端必须确认服务器的身份，并确保中间没有人。(MITM) 这是浏览器在尝试为网上银行或其他敏感操作建立安全连接时面临的相同问题。

• 这很容易使用标准 HTTPS证书（将使用 TLS 加密）进行保护。通过使用非对称密码术来保护连接，因此完成 MITM 的唯一方法是从服务器的文件系统中窃取私钥。

  证书可以由证书颁发机构颁发，每隔几年更新一次，或者您可以免费创建存储在客户端系统上的自签名证书。

现在有了 Server 身份，MITM 成功挫败；您只需要验证Client的身份。有几种方法可以继续。选一个

1. 共享密钥：只需在客户端机器上包含一个密码，服务器必须验证它是否匹配。这是验证客户端身份的最直接的方法，并且由于 HTTPS 是安全的。

2. 客户端证书作为 TLS 连接的一部分：虽然 HTTPS 为客户端证书提供了一种方式，但我发现这比必要的复杂。

3. 加密时间：为自己创建一个单独的 RSA 私钥和公钥。将公钥存储在客户端，服务器将使用私钥进行解密。客户端将加密一天中的时间，服务器将验证它是否正确。（范围内）

4. Challenge-response：在这种情况下，公钥存储在服务器上，私钥存储在客户端上。服务器向客户端发送一个随机字符串以及一个请求 ID，客户端必须能够解密该信息并将其与匹配的请求 ID 一起发送回。如果解密成功，则验证客户端身份。

   与其他方法相比，它的好处是，假设攻击者成功入侵您的服务器并下载文件，如果没有更高级的黑客攻击，他将无法冒充客户端。（尽管他会更接近 MITM）使用解决方案 1、2 和 3，只需从服务器文件系统下载适当的文件即可提供模拟客户端所需的信息。

解决方案 3 和 4 最好附带针对重放攻击的保护。解决方案 1 与 Replay 攻击防护不兼容。但是，在您的用例中，使用 HTTPS，我认为重播只是在成功破解服务器文件系统从而允许 MITM 之后的问题。

奖金：

• IP 地址：如果可能，让服务器验证连接是否源自预先确定的客户端 IP 地址。如果验证客户端 IP 地址不会更改，则此奖励保护将提供大量保护，以防止对我提供的上述解决方案的任何攻击。

代替“应用程序 1”发送数据，您可以让“应用程序 1”通知“应用程序 2”有数据要获取，然后“应用程序 2”从“应用程序 1”执行获取。

详细来说，这可能看起来像这样......

• “server 1”向“server 2”发送一个 URL（“server 2”尚未响应）
• "server 2" 在指定的 URL 处从 "server 1" 获取有效负载
• “服务器 2”处理数据，然后以适当的格式响应“服务器 1”的 POST

（注意 URL 不应该是绝对 URL）