我试图了解如何为经过身份验证的用户使用 restful 客户端来实现安全性。我遇到麻烦的场景是如何阻止用户更新不属于他自己的购买，因为 restful 客户端将购买 id 传回。对于熟练的用户，产品 ID 很容易被篡改。我对被夹在中间并不真正感兴趣，因为使用 https 可以防止或减轻它。我对尝试更新不属于他们的内容的用户非常感兴趣。
您如何在其他世界防止此类攻击？网络参数篡改
问问题
1994 次
1 回答
5
您面临的问题称为授权。一旦用户通过身份验证，就是授权授予他访问特定资源的权限。REST 场景中的授权应该在服务器端实现。
假设用户 Bob 尝试通过向/purchases/1端点发送经过身份验证的（例如，使用基本 HTTP Auth、授权会话 cookie 等）POST 请求（提供适当的有效负载）来修改购买资源。服务器的职责是验证是否允许 Bob 修改实体（例如，通过检查是否真的是 Bob 进行了购买）。如果授予权限，则服务器继续操作并以2xx 成功 HTTP 状态代码响应。否则将返回403错误代码，通知用户无权修改给定的购买。
一旦建立了授权机制，就会出现另一个问题：用户发布恶意输入以试图欺骗和克服授权机制。这涉及到一个非常广泛的 Web 应用程序安全主题。针对 webapps 的已知攻击有很多（例如注入攻击），甚至还有更多的防御方法。测试应用程序的安全漏洞称为渗透测试。值得一提的是，有执行此类测试的自动化工具（以及执行此类攻击的自动化工具）。
一般来说，您已经触及了一个非常广泛的话题，并且没有办法让一个 SO 答案来解释其中的百万分之一。将此答案视为您自己在该地区进行调查的起点。
参考
- 关于 REST 身份验证的好帖子
- Open Web Application Security Project全球非营利慈善组织，专注于提高软件的安全性
- OWASP 授权指南
- OWASP 的 REST 安全备忘单
- HTTP 状态码列表
[编辑] REST 无状态
当服务器上没有存储应用程序状态（与资源状态相反）时，API 是无状态的。单击此处可以很好地解释这两者之间的区别。有很多关于无国籍状态的讨论（特别是在身份验证的上下文中） - 查找SO或Google。
简而言之，鉴于当今的大型分布式系统，REST 中的无状态身份验证非常重要。这种环境中的服务器端应用程序状态在集群环境中的多个节点之间共享时可能会导致可伸缩性问题。这就是为什么建议让应用程序状态完全是客户端的原因。我知道一开始您可能会感到困惑，尤其是在您在我的回答中读到服务器应该授权用户操作之后。这是无状态身份验证实现的示例（数字签名的自包含会话令牌）。
但不要害怕——实际上大多数系统在服务器上至少存储了部分应用程序状态（AFAIK Google 在他们的系统中这样做）。所以就像这个答案中所说的：
“REST 不是一种宗教 (...)，您应该只遵循 REST 的原则，只要它们对您的应用程序有意义”
于 2016-03-08T22:25:22.907 回答