Security 安全建议：SSL和API访问

我的API（桌面应用程序）通过SSL使用基本HTTP身份验证与我的web应用程序通信（基本上我只是在请求中使用https而不是HTTP）。我的API实现了确保用户不会发送错误信息的逻辑，但我遇到的问题是，有人可能会绕过API，使用curl发布可能不正确的数据（因为在我的web应用上注册是免费的，所以获取凭据很简单）

我考虑过以下几种选择：

在web应用程序中复制API的逻辑，这样即使用户试图使用curl或其他工具欺骗系统，他们也会遇到相同的情况

实施进一步的身份验证检查，以确保只有我的API可以与我的web应用程序通信。（可能是SSL客户端证书？）

加密数据（基64？）

我知道我对用户用类似curl的工具欺骗我的web应用有点偏执，但我宁愿安全也不愿后悔。重复逻辑真的很痛苦，我宁愿不这样做。我不太了解SSL客户端证书，我可以将它们与基本HTTP身份验证结合使用吗？他们会让我的请求花更长的时间处理吗？我还有其他选择吗

---

提前感谢。

我大体上同意sinelaw的评论，即这种验证通常在服务器端更好，以避免您遇到的问题（支持多种客户端类型）。也就是说，你可能无法改变逻辑，在这种情况下，你需要做点什么

对我来说，你的选择是：

• 客户端证书，正如您所建议的——您基本上是在验证客户机是您希望它是谁（或者在您的情况下是什么）。我以前使用过这些，相互身份验证配置可能会令人困惑。我不会担心性能，因为我认为第一步是获得您想要的行为（正确性优先）。总之，一般来说，虽然此选项是可行的，但根据您的web容器的不同，设置此选项可能会让人恼火

• 桌面应用程序中的自定义HTTP头，在服务器端检查其存在/值，或仅利用现有用户代理头。由于您正在对流量进行加密，因此不能轻易看到您发送的HTTP头，因此您可以将其名称和值设置为您想要的任何值。在服务器端检查这一点类似于向您保证发送请求的客户端几乎肯定在使用您的桌面应用程序

我会亲自去定制标题路线。它可能不是100%完美，但如果你想做尽可能简单的事情来降低最大的风险，我觉得它是最好的方法。如果不使用HTTPS，这不是一个很好的选择（因为如果在嗅探器上翻转，任何人都可以看到标题），但是如果您使用HTTPS，它应该可以正常工作

---

顺便说一句，我认为您可能会混淆一些事情——HTTPS将为您提供加密，但它不一定涉及（客户端）身份验证。这是两种不同的东西，尽管它们常常捆绑在一起。我假设您正在使用HTTPS对实际用户进行身份验证（基本身份验证或其他任何身份验证）。

SSL保护您免受中间人攻击，但不受源于SSL客户端的攻击。客户端API中内置的客户端证书将允许您识别数据是由客户端API精心编制的，但无法帮助您确定客户端是否在数据加密之前手动修改了数据。从技术上讲，客户端的高级用户总是可以通过客户端API进行调试来找到修改数据的方法。您所能做的最好的事情就是为客户端API设置障碍，使其更难破译。服务器端的验证确实是一条可行之路

---

考虑重构您的验证代码，以便它可以在双方使用。

您必须在服务器端验证数据。如果服务器端验证失败，您可以在连接中抛出严重的错误-没关系，它们不应该被绊倒-但是如果您不这样做，您就完全容易受到攻击。（这样想：您完全控制的是服务器的逻辑，因此必须对通信的有效性做出决定性的决定。）

使用客户端证书并不能真正保护您免受那些首先有权使用API的用户的攻击；如果没有其他内容，他们可以分解代码来提取客户机证书（并且它必须对客户机代码可读才能使用）。也不会增加额外的加密；如果不在SSL连接已经提供的基础上增加更多的安全性，这将使您的工作变得更加困难（出现更多问题）。（添加加密帮助的场景是，通过HTTPS发送的消息必须通过不受信任的代理。）

---

Base-64不是加密。这只是一种更容易处理字符的字节编码方式。

在我看来，服务器端的验证是无法替代的。感谢所有人的回答，我将使用服务器端验证，不管它有多痛苦。在没有至少一些身份验证的情况下使用SSL是没有意义的；否则，您将与完全随机的对象建立安全连接，因此容易受到中间人攻击。这就是为什么SSL协议要求服务器向客户机证明其身份，通常是通过提供已知标识、来自可信标识的证书链，或者在标识和客户机请求的主机名之间进行某种匹配。或者两者的结合。同意，但让我明确一点，我说的是客户端身份验证，我认为这是问题的关键。（他说