今天我按照这个计划为我的web api（http get / post rpc style）实现了一个会话/令牌认证系统：
图例：action（param1，param2）：returnvalue1，returnvalue2
登录操作通过https发送，以保护用户数据。您将获得会话/令牌组合，其中一个令牌仅对一个请求有效（您将始终在正常请求上收到新令牌）。 我在这背后的想法是减少中间人攻击的风险，嗅探你的会话密钥：如果你“幸运”，嗅探的令牌已经通过你自己的后续请求无效。
我的后端和它的单元测试完全没问题，但我思考得不够 - 我终于遇到了异步ajax调用的问题，它打败了这个一次性令牌的想法。
增加的安全性是否值得处理异步请求？
一个想法是在我的ajax应用程序中引入一个请求队列 - 有人做了类似的事情，你会推荐吗？
可能不太安全但更方便的方法是不要为每个请求更新令牌 - 允许异步处理，但保留初始https身份验证并为会话添加严格的生命周期。我还应该将IP保存到会话服务器端。
我是否错过了其他有价值的选择？
我绑定了现有的用户名/密码值，无需例外就可以使用新的ajax应用程序进行更改。
答案 0 :(得分：1)
在我看来，您设计的令牌机制实际上并不能保护您免受中间人攻击。想象一下，中间人拦截来自客户端的每个（非HTTPS）请求，并将其替换为另一个然后发送到服务器的请求。然后，服务器返回到中间人的令牌可以简单地返回给客户端，并且客户端可能无法告知其请求从未到达服务器。
有没有办法可以通过https简单地完成所有请求？ Https为中间人攻击提供了相当大的保护，只要您使用适当的证书，并使用长时间无效的高度随机会话密钥。
答案 1 :(得分：1)
以纯文本（读取HTTP）进行身份验证后的任何后续请求都应被视为不安全，并且容易受到您可以想象的任何攻击。
如果您的目标是保护客户端与服务器之间的通信，则HTTPS是整个会话的必要条件。此外，您将需要确保在客户端从HTTP移动到HTTPS之后更改会话cookie（我假设您正在进行某种重定向，如果原始请求是HTTP）。这是一个常见错误，使客户端容易受到会话窃取攻击。
Rails的功能类似于您描述的机制。他们称他们的令牌为真品令牌。但我的理解是，主要目的是进行流量控制或双击保护，而不是实际保护通信。
答案 2 :(得分：1)
我认为HTTPS并将Session绑定到客户端IP并不时重新生成会话ID（可能每5个请求）将保护您的API。添加请求/令牌机制将提高安全性，但不再是必须的，imho。
我看到即将发生的请求/令牌系统的一个问题是，如果请求失败或没有收到答复，客户端如何重新启动通信？它没有有效的请求令牌，如果您的API正常工作，它将拒绝以下任何请求：）