RESTful架构风格下的4大常见安全问题|洞见
伴随着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/<ResourceA Id>/ResourceB/<ResourceB Id>/ResourceC/<ResourceC Id>
在
HTTP响应中缺失必要的 Security Headers
不经意间泄露的业务信息
这类ID并不会给应用造成任何技术上的威胁,只是通过ID泄露出来的信息对于你的业务而言可能非常敏感。解决办法是不使用按序递增的数字作为ID,而是使用具有随机性、唯一性、不可预测性的值作为ID,最常见的做法就是使用UUID。
返回多余的数据
前后端分离的情况下,两者之间通常以JSON作为数据传输的主体。有时候可能是为了方便前端代码处理,也可能是疏忽大意,总之后端API返回的JSON数据中包含了远远超出前端代码需要的数据,因此造成数据泄露。
例如,前端代码本意是请求订单信息,但是后端API返回的订单JSON数据中还包含了很多“有意思”的数据。
"id": 280010,
"orderItems": [...],
"user": {
"id": 100,
"password": "91B4E3E45B2465A4823BB5C03FF81B65"
},
...
}
上面这个例子里,订单数据中包含了用户信息,最为关键的是连用户的密码字段也被包含在内。
解决办法显而易见,在给前端返回数据之前,将这些敏感的、前端并不需要的数据过滤掉。技术上实现起来易如反掌,但是真正难的地方在于让整个应用都严格的按照这样的方式来处理JSON数据,确保没有任何遗漏之处。
API缺乏速率限制的保护
先看一个例子。用户注册时发送短信验证码的API,由于没有做速率限制,使得攻击者可以用一段脚本不断的请求服务器发送短信验证码,导致在短时间内耗尽短信发送配额,或者造成短信网关拥挤等等后果。
受伤的不仅仅是发送短信的API,其他一些比较敏感的API如果缺乏请求速率限制的保护,同样也会遭遇安全问题。例如用户登录的API缺乏速率限制的话,攻击者可以利用其进行用户名密码暴力破解,再例如某些大量消耗服务器资源的API如果缺乏速率限制,攻击者可以利用其发起拒绝式攻击。
解决这类安全问题的原则就是对API请求的速率进行适当的限制。具体的做法有很多,最典型的例子就是使用图片验证码,其他的做法还有利用Redis的Expire特性对请求速率进行统计判断,甚至借助运维的力量(例如网络防火墙)来共同进行防御等等。
总结
开发出一个具备足够安全性的应用不是件容易的事情,本文中提到的只是RESTful架构风格下,众多安全问题中比较典型的一部分而已。之所以会有这些问题,其本质原因在于应用开发过程中,开发团队的注意力集中在业务功能的实现上,应用安全性相关的需求没有得到足够的明确和重视。
如果你不想被这些安全问题所困扰,建议通过在应用开发过程中引入威胁建模、在用户故事卡中设立安全验收标准、进行安全代码审查等一系列安全实践,尽可能从源头上规避这些问题。
- 相关阅读 -
点击[阅读原文]到洞见网站查看文章全部内容&绿字部分。
本文版权属ThoughtWorks公司所有,如需转载请在后台留言联系。