首页 ›存档› 技术 › 查看内容

RESTful架构风格下的4大常见安全问题｜洞见

2018-3-30 13:00 |来自: 互联网 331 0

摘要: 伴随着RESTful架构风格的大量应用，一些本来难以察觉到的安全问题也逐渐开始显现出来。在我经历过的各种采用RESTful架构风格的应用中，某些安全问题几乎在每个应用中都会出现。然而它们并非是什么高深的技术难题， ...

伴随着RESTful架构风格的大量应用，一些本来难以察觉到的安全问题也逐渐开始显现出来。在我经历过的各种采用RESTful架构风格的应用中，某些安全问题几乎在每个应用中都会出现。

然而它们并非是什么高深的技术难题，只不过是借着微服务的流行而显得越发突出，这些都可以通过一些安全实践来避免。本文将一些典型的问题列举出来，希望能引起开发团队的注意，帮助他们绕过这些安全问题的“坑”。

遗漏了对资源从属关系的检查

一个典型的RESTful的URL会用资源名加上资源的ID编号来标识其唯一性，就像这样/users/100

一般而言用户只能查看自己的用户信息，而不允许查看其它用户的信息。在这种情况下，攻击者很可能会尝试把这个URL里面的USER ID从100修改为其他数值，以期望应用返回指定用户的信息。不过由于这个安全风险太显而易见，绝大多数应用都会对当前请求者的身份进行校验，看其是否是编号为100的用户，校验成功才返回URL中指定的用户信息，否则会拒绝当前请求。

对于URL中只出现一个资源的情况，绝大多数应用都已经做了安全防御，然而重灾区出现在URL中包含多个资源的时候。

以用户查看订单的RESTful URL为例：/users/100/orders/280010，应用只检查了当前请求发起者是否是编号为100的用户，以及编号为280010的订单是否存在，有很大的概率没有检查URL中的订单和用户之间的从属关系。其结果是，攻击者可以通过修改URL中的订单编号，从而遍历系统中的所有订单信息，甚至对不属于他/她的订单发起操作，例如取消订单。

上面的例子中只有两个资源，如果URL中资源数量继续增加，这种从属关系校验缺失的情况只会更加普遍。

解决这一问题的方法极其简单，只要发现URL里面出现了两个或者两个以上的资源，就像下面这样：

/ResourceA/

声明：文章版权归原作者所有部分文章转自互联网如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

收藏分享邀请

上一篇：电商基础架构建设之路下一篇：数据库真的适合容器化吗，也许不是

RESTful架构风格下的4大常见安全问题｜洞见

相关分类