原创翻译 | API中的前5名漏洞 | 数盟社区

软件应用中的安全漏洞是对(企业)安全策略的重大威胁。当前的Web应用程序都着重于把工作流逻辑放在客户端运行,而其与服务器的交互则通过API进行。开发者则根据REST的设计原则尽量的把API设计成状态不相关的。但这也变相形成了新的应用程序界面。那些设计差劲的API则很容易受到攻击。2017年有以下5大暗渠漏洞需要你特别注意:

1.DDoS

设计不好的API很容易被DDoS攻击。一般情况下是开发者没有限制API的请求频度,或者没有屏蔽恶意请求。有些API端点后面的计算逻辑非常复杂所以比较消耗资源,例如使用类似Bcrypt之类的散列算法进行认证。当攻击者发现一个这样的API端点,他们会用垃圾查询从而使整个系统崩溃。这类端点应该和主API隔离开来以便限制被攻击时对系统的影响。同时也应对不同的API设置不同的调用速率限制,当然经过验证的用户可以提高限额。

2. 资源可以被遍历可以遍历资源的 API 对于攻击者简直就是一座金矿。这是一个API设计中最常见的错误。最近印度麦当劳就被发现可以通过无需认证的公开API泄漏用户信息。这本来就已经很糟了,但是更糟糕的是用户ID居然是可以被遍历的 – 这意味着攻击者完全不需要去费力猜测用户的ID,他们只需要简单的在特定数值区间做个循环就能得到所有数据。资源遍历已经被普遍公认为最常见也是最蠢的设计缺陷了。

3. 使用未签名的URL共享资源API经常会返回一些指向超媒体例如图片音频视频等资源的链接。这些资源随后就可以被用户以任意方式使用。例如一个视频链接既可以直接用浏览器播放,也可以用类似VLC这样的播放器播放。但是这些资源都有被盗链的可能,而这会给提供者带来不少问题。例如:没有或者几乎无法进行分析,带宽和处理资源的压力,无法进行标识,无法返回最初的内容提供者。所以,对这些共享资源指定唯一以及可辨别的URL就很有必要了。签名URL就可以用来实现类似速率限制这样的策略,另外还有自动失效,限定共享范围等等。所有主要的大型网站,云存储机构以及虚拟数据中心都在使用签名URL。如果你想在自己的应用中使用签名资源,亚马逊以及Google的云服务都提供了自动给URL签名的服务。

4. 第三方库的弱点每个组织内部的工作流程都会使用很多第三方库,通常是开源或者是免费软件协议的。好处自然是开发人员无需重新造轮子,也不需要费力自己去更新这些库或者增加新的功能(尽管应该这样)。但这些外部元素以及被遗忘的安全修复,也导致了一个新的可被攻击面的出现。例如,目前很多API都使用 JWT方式认证,好处是一开始就被设计为无状态的,而且与REST原则很般配。而2015年很多常用的JWT库就被曝出发现了严重的漏洞,导致几乎全世界的开发者都被拖进了和攻击者之间的给自己API打补丁的竞赛。唯一的办法就是保持谨慎并且对外部依赖的代码进行审查,为了你自己的安全,也为了大多数人的安全。

5. 不当使用CORSCORS 本身并没有什么问题,事实当直接使用从客户(浏览器)那里得到的其他来源的资源时是很必要的,但是经常由于不恰当的实现,导致了一些并非用户本意的副作用。 例如 “Access-Control-Allow-Origin” 这个header字段经常被开发者用来允许所有来源,而实际上他们的本意是指来自他们自己网站的资源。对于公开API来说没问题,但是其他情况下就会引起盗链问题了。

英文原文:https://datafloq.com/read/top-5-vulnerabilities-in-apis/2876?utm_source=Datafloq newsletter&utm_campaign=6e921d0234-EMAIL_CAMPAIGN_2017_04_03&utm_medium=email&utm_term=0_655692fdfd-6e921d0234-95206457

 

注:转载文章均来自于公开网络,仅供学习使用,不会用于任何商业用途,如果侵犯到原作者的权益,请您与我们联系删除或者授权事宜,联系邮箱:contact@dataunion.org。转载数盟网站文章请注明原文章作者,否则产生的任何版权纠纷与数盟无关。
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.