当前位置: 首页 > 知识库问答 >
问题:

无状态服务器和无服务器端呈现的cookie中的JWT身份验证

孔欣可
2023-03-14

我试图实现jwt在cookie中的auth在一个单页应用程序的反应前端,它与运行Express的各种节点微服务通信。

我这样做,因为它似乎存储的jwt在sesionstore使应用程序容易受到XSS。

然而,通过使用cookie,API现在容易受到csrf攻击。

传统上,csrf攻击是通过创建csrf令牌,将其存储在服务器会话中,然后将其呈现在隐藏的表单字段中来减轻的。然后,在提交表单时,csrf令牌的值将与服务器会话值进行检查,以检查它们是否匹配。

我不能使用这种方法,因为:-服务器是无状态的-没有服务器端渲染。

所以我不知道应该使用哪种csrf方法。我读过关于double submit方法的书,在这种方法中,您在每个ajax请求上提交一个csrf令牌,并在cookie中存储相同的值,然后服务器检查两者是否匹配。

然而,我不能在第一时间将初始csrf令牌放入html,因为没有服务器端呈现。

在没有服务器端呈现的无状态体系结构中,在具有csrf保护的cookie中实现jwt的最佳实践是什么?

共有1个答案

姚骁
2023-03-14

只是不要将JWT令牌存储在cookie中

CSRF攻击是可能的,因为浏览器会发送带有HTTP请求的cookie,即使它们是由第三方网站上运行的脚本启动的。因此,evilsite。com可能会发送删除http://yoursite.com/items/1请求您的web服务。此endpoint要求您登录,但因为浏览器将发送为yoursite存储的任何cookie。com,如果身份验证是基于cookie的,那么将访问该站点。com可以利用您的身份验证方法,调用您的用户不打算代表他们调用的身份验证方法。

然而,身份验证不一定是基于cookie的。如果您正在创建一个客户端渲染的JavaScript应用程序,那么将身份验证令牌作为HTTP头而不是cookie发送是很简单的。如果您这样做,那么evilsite.com就不可能使用您的令牌(他们只能使用存储在cookie中的令牌),而且您从一开始就没有问题。

 类似资料:
  • 我正在为我们的应用程序使用Spring boot Microservices体系结构。在我们的项目中,我们使用的是OAuth2、Jwt、Zuul和Eureka服务,我的疑问是,我是否需要将这些服务作为一个独立的服务来实现,或者我是否可以将所有服务开发成一个单一的应用程序。 如果我必须作为单个应用程序实现,那么更好的方法是什么。请澄清

  • 它总是导致带有错误消息的catch块 登录失败:未知的用户名或错误的密码。失败:未知的用户名或错误的密码。 我确信给定的密码是正确的。 如何使用给定的密码验证用户名?

  • 问题内容: 为服务器端路由验证用户的最佳方法(最安全,最简单)是什么? 软件/版本 我使用的是最新的Iron Router 1. 和Meteor 1. ,首先,我使用的是Accounts-password。 参考代码 我有一个简单的服务器端路由,可将pdf呈现到屏幕上: 两者/routes.js 举例来说,我想做些类似于该SO答案建议的操作: 在服务器上: 然后在客户端代码中: 但是,即使我以某种

  • 问题内容: 我正在尝试制作一个服务器应用程序,以定期从自己的GA帐户提取Google Analytics(分析)数据。请注意,它是访问我自己的数据的个人服务器端应用程序,即 没有最终用户访问此应用程序。 因此,我在Google API控制台中将我的应用程序注册为 服务应用程序 ,这给了我一个 客户端ID 和一个 私钥 。据我了解,服务应用程序不使用 应用程序密钥 和 重定向URL, 因为此服务器到

  • 出身背景我需要让我的网站通过IdentityServer(IDS)进行身份验证。“example.com” 我正在用DotNetCore构建我所有的网站,用apache在代理服务器上托管它们,让我们调用私有ip12.3.4.5。 它们应该如何工作。我去网站的例子。我应该可以和ids通话。例如。com获取身份验证信息,然后重新路由回示例。具有身份验证令牌的com。相反,我得到了一个SSL握手错误。见

  • 我想用jwt流实现DocuSign服务集成身份验证。 我已经生成了有效的jwt(在jwt.io上验证),并且我可以根据https://docs.docusign.com/esign/guide/authentication/oa2_jwt.html#requesting-访问令牌 我在这篇博文中发现:https://www.docusign.com/blog/dsdev-docusign-deve