什么是SQL注入?理解、风险与防范技巧
为什么业务逻辑漏洞是您的首要 API 安全风险
您可能认为需要编写数百行代码才能突破最安全的网络防御。但实际上,网络犯罪分子通常会通过 API 的标准功能以您意想不到的方式访问您的敏感数据。
这些漏洞被称为业务逻辑缺陷,它们是对您的 API 安全的最大威胁。
什么是业务逻辑缺陷?
业务逻辑漏洞是 API 设计中的缺陷,它允许攻击者操纵合法功能、数据或工作流程来达到恶意目标。
业务逻辑缺陷非常普遍,以至于五大OWASP API 攻击媒介中有四个与这类漏洞有关,因此了解它们的工作原理至关重要。
从提升用户权限到破坏数据库,关键因素在于这些缺陷是由于对系统不同部分的工作和交互方式的错误假设而产生的。
举一个现实世界的例子,业务逻辑漏洞是导致美国邮政服务大规模数据泄露和 6000 万条敏感用户数据记录泄露的根本原因,给该组织的声誉留下了永久的污点。
阅读更多:什么是 API 安全以及它为何如此重要
商业逻辑缺陷是如何产生的?
API 是允许通过防火墙的管道。如果测试不当,它们可能会存在漏洞(本质上是设计上的漏洞),存在业务逻辑缺陷。
– Corey Ball,网络安全咨询经理兼《Hacking API》作者
当攻击者试图使用恶意软件、SQL 注入或其他技术访问您的网络系统时,即使是最基本的安全措施也可能会触发警报并警告您的安全团队正在发生网络攻击。
如果存在商业逻辑缺陷,那么情况就完全不同了。
想象一下这样一个场景:您的开发团队忽略了允许在显示用户银行账户当前余额的页面上使用 HTTP 请求方法的限制协议。攻击者可能会使用 PUT 方法来编辑该值或完全删除该记录。
由于此类逻辑缺陷发生在合法 API 功能范围内,因此它们通常不会在您的数据被泄露很久之后触发任何警报(如果有的话)。
企业因数据泄露而遭受财务损失、客户信心下降、声誉受损,甚至破产。
阅读更多:什么是 API 测试?
最常见的商业逻辑缺陷类型有哪些?
虽然业务逻辑缺陷是基于给定 API 架构的独特漏洞,但我们可以找出最常见的类型,以帮助您领先于网络犯罪分子。
1. 滥用 HTML 元素和其他客户端代码
网页通常使用 HTML 构建,其中包含可在客户端使用 JavaScript 等脚本语言更改的动态元素。但是,当这些元素容易受到外部参与者的操纵时,它们可能会带来巨大的安全风险。
如果攻击者可以改变这些元素以进行未经授权的查询,他们就可以绕过任何防火墙来访问敏感数据。
2. 授权绕过
一种称为授权绕过的漏洞允许某些用户访问超出其授权级别的信息。由于这种漏洞的范围非常广泛,因此许多级别和实例的网络攻击都属于这一类别也就不足为奇了。
损坏的对象级授权 (BOLA) 已经位居 OWASP API 安全前 10 名榜单的首位 – 这是有充分理由的。API 提供商在确保用户通过 API 身份验证方面做得非常出色,因此他们希望确保合法用户可以访问。
但最容易被忽视的一点是授权,即确保用户 A 无法访问用户 B 的资源。隐藏资源 ID 是一回事,但重要的一点是用户 A 根本无法访问、交互或更改用户 B 的资源。
– Corey Ball,网络安全咨询经理兼《Hacking API》作者
授权绕过的两种最常见子类型包括:
- 横向移动:访问同一权限级别的其他账户的数据
- 权限提升:访问当前权限级别无权访问的数据
应该实施强大的授权和身份验证协议(例如OAuth或 OpenID),以防止绕过授权并保护您的系统免受此攻击媒介的侵害。
3. 无法处理非常规用户输入
攻击者可以通过向开发人员未能预料到的 API 提供输入来触发系统的意外响应,从而可能暴露敏感数据。
许多 API 缺乏其他攻击载体所具备的安全控制,这使得它们相当于死星的热排气口:一条通往企业厄运和毁灭的道路。
– Corey Ball,网络安全咨询经理兼《Hacking API》作者
在处理非常规用户输入时,企业必须非常小心,并对所有数据类型(包括意外的值和字符)进行细致的测试。
他们可以通过运行一系列模糊测试来向系统提供不同类型的随机用户输入来实现这一点。
4. 过度信任用户
许多IT系统过于信任其授权用户,从而产生大量安全潜在的安全漏洞。
如果攻击者可以访问真实管理员用户的登录凭据(无论是通过网络钓鱼攻击还是简单地在暗网上购买这些数据),他们就可以轻松潜入、访问数据库并造成数据泄露,类似于导致30 亿条雅虎记录泄露的事件。
为了保证您自己的安全,您必须假设每个用户都是潜在的安全威胁,无论是否获得授权。
这就是零信任安全模型的全部内容,确保每个用户都得到适当的授权和身份验证——同时在允许他们进入后监控他们的行为。
5. 特定领域的缺陷
特定领域缺陷是系统中仅存在于特定领域的弱点。
与影响整个应用程序的一般漏洞不同,特定领域的缺陷仅存在于特定的模块或功能中。
这个关键方面使得它们更难识别和修复,因为您需要深入了解攻击者可能通过滥用特定领域的缺陷来尝试实现的目标。
您掌握的有关最终用户行为的信息越多,就越容易准确识别和标记可疑行为。
一个好的起点是利用 API 管理工具的分析和报告功能来识别和分析使用模式。
如何预防和测试 API 安全中的业务逻辑缺陷
有效的 API 安全测试至关重要。如果我们回想一下 USPS 数据泄露事件,该事件是在 6000 万份私人数据泄露事件发生前一个月进行的测试。这并不是说您只是对 API 进行一般性测试,而是使用正确的工具和技术来帮助您的 API 安全漏洞管理程序很好地防止此类攻击。
– Corey Ball,网络安全咨询经理兼《Hacking API》作者
现在您已经了解了最常见的业务逻辑缺陷类型,是时候采取一些措施来解决这个问题了。
以下是测试 API 安全性中的业务逻辑缺陷的一些技巧:
1.确保您的测试用例涵盖所有可能的情况
确保您的 API 安全性严密的第一步是设计尽可能多的测试用例,以涵盖所有可能的攻击场景。
测试的攻击场景越多,识别底层业务逻辑漏洞的机会就越大。
这就是您需要深入了解 API 的各个方面以创建真正起作用的测试用例的地方。
API 可以直接访问敏感数据。它们连接到您的应用服务器、微服务和数据库应用程序,因此必须非常安全。而且许多 API 的权限过多 – 对于其中一些 API,您甚至没有意识到它们可能泄露了凭据。
– Cecil Pineda,CISO XC 联合创始人
2. 验证所有用户输入
默认将用户输入视为安全威胁。此方法需要验证所有用户输入,无论其来自何处或由谁提交。
这样,您就可以保护自己免受整个 API 漏洞层的攻击,并大幅降低与内部威胁相关的风险。
所有无效输入都应被记录并最终进行监控,以发现可能导致数据泄露的潜在漏洞。
零信任安全模型已被证明可以有效减少网络安全事件的数量,因此将其应用于您的 API 是一个好主意。
3. 改进你的 API 文档
确保您的 API 有足够的文档记录,以便开发人员能够了解其工作原理。
这将提高您的采用率并帮助您发现业务逻辑中的任何错误或不一致之处。
记录良好的 API 将使您更容易测试安全漏洞。
4. 监控异常行为并定期检查所有访问日志
API 日志记录和监控对于保护您的用户免受网络攻击至关重要。
没有任何系统能够完全安全,因此对于您的团队来说,不断跟踪和分析所有可审计事件(从失败的登录到大额交易)至关重要。
一些用户操作可能会指向一个关键的业务逻辑漏洞,因此要密切关注您的日志。
5.使用自动化 API 安全测试工具
如果您对这些信息感到不知所措或者不知道从哪里开始,那么自动化您的安全测试是一个很好的起点。
问题在于,即使拥有一支开发团队,业务逻辑缺陷也极难识别和检测。
通常,开发人员是你工资单上最昂贵的员工。
流行的 API 测试工具缺乏真正保护您的 API 所需的深度,因为安全性不是它们的专长,只允许您自动执行仍然必须手动创建的数千个测试用例。
文章来源:Why Business Logic Vulnerabilities Are Your #1 API Security Risk