如何进行无状态(无会话)和无cookie身份验证？
王小贱 发布于 2023-02-10 13:42Bob使用Web应用程序来实现某些目标.和:
他的浏览器正在节食,因此它不支持cookie.
Web应用程序是一个受欢迎的应用程序,它在特定时刻处理许多用户 - 它必须很好地扩展.只要保持会话会对同时连接的数量施加限制,并且当然会带来不可忽视的性能损失,我们可能希望有一个无会话系统:)
一些重要的说明:
我们有运输安全(HTTPS及其最好的朋友);
在幕后,Web应用程序代表当前用户将大量操作委托给外部服务(这些系统确实将Bob视为其用户之一) - 这意味着我们必须转发Bob的凭据.
现在,我们如何验证Bob(在每个请求上)？哪个是合理的方式来实现这样的事情？
通过HTML表单隐藏字段打网球凭证... 球包含凭据(用户名和密码),两个球拍分别是浏览器和Web应用程序.换句话说,我们可以通过表单字段而不是通过cookie来回传输数据.在每个Web请求中,浏览器都会发布凭据.虽然,在单页应用程序的情况下,这可能看起来像在橡胶墙上打壁球而不是打网球,因为包含凭证的Web表单可能在网页的整个生命周期(和服务器)中保持活动状态将被配置为不提供凭证).
将用户名和密码存储在页面上下文中 - JavaScript变量等.这里需要单页,恕我直言.
加密的基于令牌的身份验证 在这种情况下,登录操作将导致生成加密的安全令牌(用户名+密码+其他内容).该令牌将被返回给客户端,即将到来的请求将伴随令牌.这有意义吗？我们已经有了HTTPS ...
其他...
不得已:不要这样做,在会话中存储凭据!会议很好.有或没有饼干.
对于任何先前描述的想法,是否存在任何网络/安全问题？例如,
超时 - 我们可以保留时间戳和凭证(时间戳= Bob输入凭证的时间).例如,当NOW - timestamp> threshold时,我们可能会拒绝该请求.
跨站点脚本保护 - 不应该有任何不同,对吧？
非常感谢您花时间阅读本文:)
-
啊,我喜欢这些问题 - 在没有会话的情况下维持会话.
在应用程序评估期间,我已经看到了多种方法来执行此操作.其中一种流行的方式是你提到的打网球方式 - 在每个请求中发送用户名和密码来验证用户身份.在我看来,这是不安全的,特别是如果应用程序不是单页面.它也是不可扩展的,特别是如果你想在未来的身份验证中添加授权给你的应用程序(虽然我猜你也可以根据登录构建一些东西)
一种流行的,虽然不是完全无状态的机制(假设你有JavaScript执行)是在JavaScript中嵌入会话cookie.我这里的安全人员正在为此尖叫,但实际上它可以工作 - 每个请求都有一个
X-Authentication-Token标题或类似的东西,然后你将它映射到后端的数据库,内存中的文件存储等,以验证用户.此令牌可以在您指定的任何时间超时,如果超时,则用户必须再次登录.它具有相当的可扩展性 - 如果将其存储在数据库中,执行一个SQL语句,并且使用正确的索引,即使有多个并发用户,也只需要很少的时间来执行.这里负载测试肯定会有所帮助.如果我正确地阅读了这个问题,这将是你的加密令牌机制 - 尽管如此,我强烈建议你使用32字符的加密随机令牌,而不是使用用户名+密码+其他任何东西的组合 - 这样,它就会停留不可预测,但您仍然可以将其与用户ID或某些此类事物相关联.无论您最终使用哪种,请确保它安全地发送给您.HTTPS通过网络保护您,但如果您通过URL泄漏会话令牌(或者更糟糕的是,通过URL凭据),它不会保护您.我建议使用标头,或者如果这不可行,每次都通过POST请求发送令牌(这将意味着用户浏览器上的隐藏表单字段.)后一种使用POST请求的方法应该使用CSRF防御,只是万一,虽然我怀疑使用令牌本身可能是某种CSRF防御.
最后,但并非最不重要,请确保后端有一些机制来清除过期的令牌.这是过去许多应用程序的祸根 - 一个快速增长的身份验证令牌数据库,似乎永远不会消失.如果您需要支持多个用户登录,请确保限制数量,或者对每个令牌设置更短的时间限制.正如我之前所说,负载测试可能就是答案.
我还可以考虑其他一些安全问题,但是它们太宽泛而无法在此阶段解决 - 如果你记住所有的使用(和滥用)案例,你应该能够做一个相当好的实现这个系统.
2023-02-10 13:46 回答
此号我已不再用
京公网安备 11010802041100号