在网站中实现某些角色特定功能时,我遇到了一个有趣的问题.
这就像,如果登录用户具有管理员角色权限,那么将启用一个按钮(称为转移),否则应该禁用其他用户(因此他们无法点击因此无法执行事务/或调用相关的逻辑)
一目了然,它似乎相当直接的UI验证有点东西.如果登录用户具有管理员权限,我们只需启用该按钮即可.
因此,在实施该方法(工作正常)后,我使用Chrome开发人员工具调试代码.我注意到虽然现在禁用了按钮,但我们可以通过使用该工具删除禁用的部件来实现它.
Just try it with this simple fiddle
然后我可以点击它并调用函数.所以基本上这不是好方法.但幸运的是,还有服务方验证.但如果不是这可能是一个巨大的安全漏洞.
所以基本上做服务器/服务/后端验证可以防止发生危险.但是,因为这个人实际上可以点击它,至少他可以尝试调用方法似乎不太好:(
所以,我真的很想知道,我们怎样才能防止这种情况发生.
好的,我的问题很简单：
有残疾组件是否好？
这是您的业务逻辑的一部分,不应该出现在DOM中…
“但是嘿：)……”
现在,即使元素不存在,也没有什么可以阻止用户手动将这样的元素嵌入到您的网站中.
您应始终执行服务器端检查以查看此用户具有执行特定操作的实际权限.
有时在UI内部使用禁用元素来向用户显示：
“嘿,看到这个按钮？除非你支付或者说等等,否则不适合你”,
但通常作为第二步/可选动作元素.
有时整个表单在网站上是“可见的”,但是已经对齐/禁用.
这样的使用案例是：带有步骤的付款表格,设计者希望向用户说明他需要填写以前的表格,以“激活”第二个表格并继续付款等…案例是无穷无尽,但如果网站上存在一个表单,那就是纯UI(View),除非(如我所说)业务逻辑指定,否则模型绝不应接受来自控制器的值.
请记住,前端Javascript仅用于通过直观的界面系统通知和帮助用户. JS事件应该只是为了反映用户可以和不可以做什么.
由于JS可以被任何精通技术的用户绕过,在后端,您需要再次重建类似且更强大的安全逻辑.
(！)验证前端的用户输入,但最重要的是 – 在后端.
Can firebug or developer tools use to hack a web site?
直？
>是的
>如果可以通过操纵View(源)来利用网站后端逻辑.
>如果您保留了访问浏览器的代码(在评论等中)敏感信息.
>不
>如果某个网站不允许使用XSS,则具有强大的后端安全性.
间接？
恶意用户最终可能会要求用户打开控制台(欺骗用户控制台是实际的网站功能)并向他发送(复制/粘贴)存在于其中的私人信息,例如会话密钥,cookie等. .
