我的API（桌面应用程序）使用SSL上的基本HTTP身份验证与我的Web应用程序通信（基本上我只是在请求中使用https而不是http）。我的API实现了逻辑，确保用户不会发送不正确的信息，但我遇到的问题是，有人可以绕过API并使用curl潜在地发布不正确的数据（因为注册我的网络应用程序是获取凭据是微不足道的自由）。
我考虑过以下几个选项：
在Web应用程序中复制API的逻辑，这样即使用户试图使用curl或其他工具欺骗系统，它们也会显示相同的条件。
实施进一步的身份验证检查，以确保只有我的API可以与我的网络应用程序通信。 （也许是SSL客户端证书？）。
加密数据（Base 64？）
我知道我对用户使用类似卷曲的工具欺骗我的网络应用程序有点偏执，但我宁愿安全而不是抱歉。复制逻辑真的很痛苦，我宁愿不这样做。我对SSL客户端证书了解不多，我可以将它们与基本HTTP身份验证结合使用吗？他们会让我的请求需要更长的时间来处理吗？我还有其他选择吗？
提前致谢。
答案 0 :(得分：2)
我一般会同意sinelaw的评论，即在服务器端进行此类验证通常会更好，以避免您遇到的问题（支持多种客户端类型）。也就是说，你可能无法移动逻辑，在这种情况下你需要做一些事情。
对我而言，您的选择是：
客户端证书，正如您所建议的那样 - 您基本上是在验证客户端是您期望的客户（或者您的情况）。我以前使用过这些，相互认证配置可能会令人困惑。我不担心性能，因为我认为第一步是获得您想要的行为（正确性首先）。无论如何，一般来说，虽然这个选项是可行的，但根据您的网络容器设置可能会令人恼火。
桌面应用程序中的自定义HTTP标头，检查服务器端的存在/值，或者仅利用现有的User-Agent标头。由于您正在加密流量，因此您应该无法轻松查看正在发送的HTTP标头，因此您可以将其名称和值设置为您想要的任何内容。在服务器端检查这一点类似于向您保证发送请求的客户端几乎肯定会使用您的桌面应用程序。
我个人会去自定义标题路线。它可能不是100％完美，但如果你对做最简单的事情以减轻风险感兴趣，它会让我感到最好。如果你不使用HTTPS，这不是一个很好的选择（因为任何人都可以看到标题，如果他们翻转嗅探器），但鉴于你确实使用HTTPS，它应该工作正常。
顺便说一下，我认为你可能会混淆一些东西 - HTTPS会给你加密，但它不一定涉及（客户端）身份验证。这是两件不同的事情，虽然它们经常被捆绑在一起。我假设您正在使用HTTPS来验证实际用户（基本身份验证或其他）。答案 1 :(得分：2)
SSL可以保护您免受中间人攻击，但不会受到源自SSL客户端的攻击。客户端API中内置的客户端证书允许您识别数据是由客户端API精心设计的，但无法帮助您确定客户端是否在加密之前手动修改了数据。技术上客户端上的ssavy用户总是可以通过客户端API调试来找到修改数据的方法。您可以做的最好的事情就是将障碍物放到客户端API上，以便更难解读它。服务器端的验证确实是可行的方法。
考虑重构验证码，以便双方都可以使用。
答案 2 :(得分：2)
你必须验证服务器端的数据。如果服务器端验证失败，你可以在连接中抛出讨厌的错误 - 没关系，他们是不应该被绊倒 - 但如果你不这样做，你完全是脆弱的。 （以这种方式思考：这是您完全控制的服务器逻辑，因此服务器的逻辑必须做出关于通信有效性的明确决定。）
使用客户端证书对于那些首先有权使用API的用户来说，并不能真正保护你;如果没有别的，他们可以拆开代码来提取客户端证书（并且它必须是可读的客户端代码才能使用）。也不会增加额外的加密;它使你的事情变得更加困难（更多的事情出错），而不会增加SSL连接已经提供的安全性。 （添加加密有助于通过HTTPS发送的消息必须通过不受信任的代理进行的情况。）
Base-64不是加密。它只是一种将字节编码为易于处理的字符的方法。