我在使用用于检查控制器中的用户权限的声明时遇到了很多麻烦。
应用结构
我们的后端是.NET Core，前端是React，而现在我们只允许使用谷歌API使用谷歌启用的电子邮件登录。我们生成一个JWT并将其存储在浏览器的localStorage上，然后在每次请求时发送它。此外，没有角色：如果您已登录，那么您就是管理员。
开发应用程序＆＃34;骨架的开发者＆＃34;现在已经不见了，这是我第一次处理安全问题。
新要求
我们现在需要实现角色和权限，似乎MS希望为此使用声明。我做了这个，并将这些声明添加到jwt，然后在配置上添加了策略，它实际上工作。如果您有特定声明，则可以访问特定控制器或方法，否则服务器将返回403错误。
但后来我以实际的管理员角色登录，使用devtools复制了localStorage值，然后注销并重新登录，几乎没有权限的用户。当我粘贴本地存储条目（再次使用devtools）时，我立即获得了所有声明，并且能够访问管理员可以访问的每个控制器和方法。
似乎正确的方法应该是使用HttpOnly，安全的cookie，也许使用＆＃34; SameOrigin＆＃34;设置为true（不确定这会影响单点登录），但我不明白如何这样做。我看过博客文章，甚至下载了一个应用程序（我无法运行，但我将代码复制到我的应用程序），但我一直都失败了。另外，我不清楚在检查控制器策略时是否需要对cookie进行任何操作。
任何人都可以帮我解决这个问题吗？
答案 0 :(得分：0)
问题在于，如果攻击者能够进入用户的浏览器，他/她可能会造成比仅仅窃取access_token更多的伤害。在Auth0.com上查看this thread。基本上是：
让我们假设您可以从某人的浏览器中窃取JWT。 根据您的工作方式，可能有两种情况：
- 你要么在某种情况下造成更大的伤害，而不仅仅是偷一个令牌。
- 你不是，想象一下，如果不是存储JWT你的实际密码被盗，那就更糟了。
主要区别在于，Cookie更容易受到XSRF的攻击，而JWT更容易受到XSS的攻击。
另外，如果您选择基于JWT的Cookie，还有一个有用的引用：
Cookie的PRO是：
- 假设您愿意使用HttpOnly cookies
，对XSS更安全缺点是：
- 您无法使用JS代码访问JWT。
- 您需要保护针对CSRF的请求，因为标头方法不会受到此影响，但Cookie会受到影响。
- 您的API代码需要处理来自Cookie（来自浏览器）或来自标头的JWT（其他服务器需要调用您的API） 使用标题）。
- 如果您的API与您的网站位于同一个域中，则Cookie可以正常运行。如果API位于不同的域中，则不可用。
关于从cookie而不是http标头验证JWT的第三点，您需要按照here所述修改中间件。
就个人而言，如果您使用ReactJS，我会保留JWT模型，因为它对SPA应用程序来说更suitable。处于你描述的情况：＆＃34; 当我粘贴本地存储条目（再次使用devtools）时，我立即获得了所有声明＆＃34;基本上意味着攻击者坐在计算机前面，在这种情况下窃取JWT令牌变得不那么重要了。
请记住，您需要为JWT代币设置到期日期，然后您应该没事。