wor*_*red 1 security rest authorization web-applications rest-security
我试图了解如何使用restful客户端为经过身份验证的用户实现安全性.我遇到麻烦的情况是如何阻止用户更新不属于他自己的购买,因为宁静的客户通过了购买ID.对于熟练的用户,产品id可以容易地被篡改.由于使用https可以阻止或减轻它,因此我并不感兴趣.我真的对试图更新不属于他们的用户感兴趣.
你如何在其他世界阻止这种攻击？Web参数篡改
您面临的问题称为授权.一旦用户通过身份验证,授权就授予他访问特定资源的权限.应在服务器端实现REST方案中的授权.
假设用户Bob尝试通过向/purchases/1端点发送经过身份验证(例如,使用Basic HTTP Auth,授权会话cookie等)POST请求来尝试修改购买资源(提供适当的有效负载).服务器有责任验证是否允许Bob修改实体(例如,通过检查是否真的是Bob进行了购买).如果授予了权限,则服务器继续执行操作并以2xx成功HTTP状态代码进行响应.否则将返回403错误代码,通知用户无权修改给定的购买.
一旦建立了授权机制,就会出现另一个问题:用户发布恶意输入以试图欺骗和克服授权机制.这触及了一个非常广泛的Web应用程序安全主题.有许多已知的针对webapps的攻击(例如注入攻击)以及更多防御它们的方法.测试安全漏洞的应用程序称为渗透测试.值得一提的是,有自动化工具可以执行此类测试(以及执行此类攻击的自动化工具).
总的来说,你已经触及了一个非常广泛的话题,并且没有办法用SO答案来解释百万分之一.将此答案视为您在该地区进行调查的起点.
当服务器上没有存储应用程序状态时,API是无状态的(与资源状态相反).点击这里了解这两者之间的区别.有很多关于无状态的讨论(特别是在身份验证的背景下) - 查找SO或Google.
简而言之,鉴于当今的大型分布式系统,REST中的无状态身份验证非常重要.此类环境中的服务器端应用程序状态在群集环境中的多个节点之间共享时可能会导致可伸缩性问题.这就是为什么建议将应用程序状态完全设置为客户端.我知道一开始可能会让你感到困惑,尤其是在我的答案中你已经阅读了服务器应该授权用户操作之后.以下是无状态身份验证实现(数字签名的自包含会话令牌)的示例.
但不要害怕 - 实际上,大多数系统都存储服务器上至少部分应用程序状态(AFAIK Google在他们的系统中执行此操作).就像在这个答案中所说:
"REST不是一种宗教信仰(......),你应该只遵循REST的原则,只要它们对你的应用程序有意义"
| 归档时间： |
|
| 查看次数： |
1052 次 |
| 最近记录： |