【问题标题】:Secure client-side conditional rendering of auth validation dependent components如何“安全地”验证客户端的条件渲染
【发布时间】:2022-12-18 08:03:15
【问题描述】:

借助浏览器的 devtools 重新加载已编辑的 javascript 覆盖的能力,您如何“安全地”执行依赖于验证的前端代码?

假设您想根据授权用户的权限有条件地显示某种专有 UI 元素(幽默)。授权用户数据将通过承诺进行验证,但如果条件是基于返回的承诺数据的客户端,那么有人不能删除该条件,另存为覆盖并重新加载页面吗?

if (permissionGroup == 'Team'){
  return <>{children}</>
}

if (nodeENV !== 'development'){
  checkAuth();
}

编辑并运行 JS 覆盖以在不运行身份验证检查的情况下返回孩子

if (permissionGroup !== 'anything'){
  return <>{children}</>
}

有什么办法可以防止这种情况?我对 devtools 安全性的了解有误吗?或者行业标准是否理解,除了数据之外,任何客户端本质上都是开源的?

【问题讨论】:

  • 不要完全在客户端进行身份验证
  • 从客户端保护总是很复杂,在现实世界中,安全的东西是在后端制作的
  • 每个人都知道安全存在于服务器端。我在问一个特定于客户端的问题。 “构建静态站点”不是有关 SPA 问题的相关答案
  • 如果您可以控制用户的浏览器,则可以防止这种情况(有点)。事实上,我工作的公司就是这样做的。但实际上不可能在客户端保护客户端资源。在像 Angular 这样的框架中,你可以使用守卫。即使那样,不良行为者也可以规避仅客户端受保护的资源。

标签: javascript reactjs security frontend devtools


【解决方案1】:

您永远不会信任客户端,正如您提到的那样,客户端可以修改代码并覆盖您的“安全功能”。

您将需要一个后端并需要验证客户的输入。

【讨论】:

  • 请原谅我,但我正在寻找更深入的解释。每个人都知道安全是服务器端的责任,而不是信任客户端。有些技术在客户端执行是有原因的。我要问的是,如果要求客户端条件必须安全,您是否以及如何执行依赖于安全值的客户端代码。即有条件地渲染 SPA 中的反应组件。就在那时,任何类型的客户端渲染在技术上都不适合该要求吗?
猜你喜欢
  • 2013-11-14
  • 1970-01-01
  • 1970-01-01
  • 2018-08-09
  • 1970-01-01
  • 2018-08-24
  • 1970-01-01
  • 1970-01-01
  • 2018-04-11
相关资源
最近更新 更多