kavin

API的五个常见漏洞

kavin 安全防护 2022-11-22 511浏览 0

API让天下没有难做的生意,黑客也是这么认为的。在企业数字化转型如火如荼的今天,API已经远远超出了技术范畴,互联网商业创新和传统企业数字化转型都离不开API经济或者API战略。API连接的不仅仅是系统和数据,还包括企业职能部门、客户和合作伙伴,甚至整个商业生态。与此同时,日益严峻的安全威胁,使得API正在成为网络安全的下一个前沿阵地。

API使一切都变得更加容易,从数据共享到系统连接到关键功能的交付,但API也使攻击者(包括恶意机器人)更容易进行攻击。API的应用激增,正刺激网络犯罪分子越来越多地利用API安全漏洞进行欺诈和窃取数据。

以下,我们将探讨容易被黑客利用的五个API漏洞,并分享安全专家们给出的缓解和强化建议。

API的五个常见漏洞

一、太容易被发现

假如你是黑客,准备攻击一家企业,那么首先要做的第一件事就是识别尽可能多的API。我首先按常规方式使用目标应用程序,在浏览器中打开Web应用程序或者在手机端下载安装移动应用程序,然后使用拦截代理监视通信。

拦截代理能够捕获浏览器或移动应用程序对后端Web服务器发出的所有请求,从而使攻击者可以对所有可用的API端点进行分类。例如,大多数API都将API/V1/login作为身份验证端点。

如果目标也是移动应用程序,则将应用程序包拆开,并查看应用程序内部可用的API调用。考虑到所有可能的活动,攻击者可以搜索无法正确保护用户数据的常见配置错误或API。

最后,攻击者寻找API文档。一些组织为第三方发布API文档,但为所有用户使用相同的API端点。

有了一个不错的端点清单,攻击者就可以测试标准用户行为和异常行为测试,可以通过两种方法找到有趣的漏洞。

解决方法:为了使攻击者更加难以发现API,请确保通过仅允许有效用户访问的权限管理来控制对API文档的访问。虽然将证书固定在移动应用程序上并不能完全隐藏API端点,并且也不完美,但确实给攻击增加了额外的步骤。对Web服务器的API请求应尽可能地被混淆和控制。

二、过于详细的错误信息

最近,攻击者接管账户的尝试在不断增加。错误消息过于“详细周到”,往往使此类攻击更加容易。冗长的错误消息会引导攻击者了解他们需要进行哪些更改才能伪装成合法请求。API专为低负载下的高速交易而设计,使攻击者可以使用高性能系统找出有效账户,然后尝试登录并更改密码进行利用。

解决方法:不要拿用户体验作为挡箭牌,有些看起来有利于用户体验的做法,未必有利于安全性。系统返回的错误信息不应该包括错误的用户名或错误的密码,甚至不能包含错误信息的类别(用户名还是密码错误)。用于查询数据的错误消息也是如此,如果查询/搜索格式不正确或由于某种原因而无法执行,则应该返回最“没有营养”的错误信息:“糟糕,哪里出错了”。

三、参数太多

当攻击者通过API调用遍历攻击系统时,他们必须弄清楚可以发送些什么来获取数据。攻击者“信奉”这样的一个事实:即越复杂的系统,出错的地方越多。攻击者识别出API后,他们将对参数进行分类,然后尝试访问管理员(垂直特权升级)或另一个用户(水平特权升级)的数据以收集其他数据。通常,太多不必要的参数被暴露给了用户。

在最近的研究项目中,我们对目标服务的API调用返回了大量数据,很多都是不必要的数据信息,例如付款网关的处理器密钥和可用的折扣信息等。这些“奖励信息”使攻击者可以更好地理解这些API调用的上下文和语法。攻击者不需要太多的想象力就能弄清楚下一步该怎么做。这些额外的参数为攻击者提供了丰富的攻击数据集。

解决方法:如果将用户看到的内容范围限制为必需内容,限制关键数据的传输,并使数据查询结构未知,那么攻击者就很难对他们知道的参数进行暴力破解。

四、数据过多

同样地,由于可用的参数太多,收集数据将成为显而易见的下一步行动。许多企业的系统支持匿名连接,并且倾向泄漏普通用户不需要的额外数据。另外,许多企业倾向于存储可以直接访问的数据。

安全专业人员正在努力应对API请求经常暴露数据存储位置的挑战。例如,当我查看安全摄像机中的视频时,可以看到该信息来自Amazon S3存储库。通常,那些S3存储库的保护并不周全,任何人的数据都可以被检索。

另一个常见的数据挑战是数据过载,很多企业都像入冬前的花栗鼠,存储的数据量远远超出了需要。很多过期客户数据已经没有商业价值和保存价值,但是如果发生泄露,则会给企业带来巨大的品牌和合规风险。

解决方法:对于存储用户数据的企业,不仅仅是PII或PHI,都必须进行彻底的数据审查。在检查了存储的数据之后,应制定数据访问规则并进行测试。确保能够匿名访问的数据不涉及任何敏感数据。

五、安全设计太少

多年以来,应用程序设计总是优先考虑功能性和可用性,很少考虑安全性。很多CISO表示,API安全性尤其不被重视,甚至完全被排除在安全设计流程之外。通常都是开发人员开发和部署完成后,在API投入生产且频繁遭受攻击后才亡羊补牢查找问题。安全性(包括API安全性)需要成为产品设计的一部分,并且应作为首要考虑因素之一加以实现,而不是事后填坑。

解决方法:审查应用程序的安全体系结构是迈向安全系统的重要第一步。请记住,API使攻击者能更高效地攻击或利用您的系统。设计安全性的目标是让API成为用户而非攻击者的高效工具。

以上只列举了一些常见的API漏洞,总之,最重要的是在软件开发生命周期的早期阶段就讨论安全问题。微小的改进就可以带来巨大的好处,避免API遭攻击造成的巨大财务和品牌损失。

继续浏览有关 安全 的文章
发表评论