流量反作弊（8）【Draft】OWASP-API安全top 10 2023年变化解读

发表于 更新于 分类于 ， ， ， 阅读次数： 本文字数： 11k 阅读时长 ≈ 20 分钟

【TODO】OWASP API安全 top 10 2023变化解读

问题定义，【问题危害】，变化比较（变化原因），场景分析，【案例分析】, 缓解措施

2019 2023 变化
API1:2019 Broken Object Level Authorization API1:2023 Broken Object Level Authorization 水平越权
API2:2019 Broken User Authentication ‍API2:2023 Broken Authentication 范围从”人“的认证，扩展到了”人+机“的认证
API3:2019 Excessive Data Exposure API3:2023 Broken Object Property Level Authorization 合并了API3（过度数据暴露）+API6（批量分配）
API4:2019 Lack of Resources & Rate Limiting ‍API4:2023 Unrestricted Resource Consumption 应用层Dos，强调了后果（后端资源）
API5:2019 Broken Function Level Authorization API5:2023 Broken Function Level Authorization 垂直越权
API6:2019 Mass Assignment ‍API6:2023 Server-Side Request Forgery (SSRF)
API7:2019 Security Misconfiguration API7:2023 Security Misconfigurations
API8:2019 Injection API8:2023 Lack of Protection from Automated Threats 业务风控/爬虫/Bot保护
API9:2019 Improper Assets Management API9:2023 Improper Inventory Management 强调了”未下线的老版本API/临时调试API“风险暴露面
API10:2019 Insufficient Logging & Monitoring API10:2023 Unsafe Consumption of APIs 供应链角度：开发人员信任第三方API而不继进行检验

伴随企业数字化程度的加深，API成为软件世界数据交互的“通用语言”，其数量迎来爆发式增长。同时，API的广泛应用也为运维可见性、安全性提出了新的挑战。针对API这种“易攻难守”的新兴资产的安全治理显得愈发重要。

OWASP为强调API安全的重要性，在2019年首次提出了API Security Top 10。后随着安全产业实践加深，于2023年发布了API Security Top 10（候选版）的内容更新。该更新内容进一步强调了API攻击场景与Web攻击的差异化，突出API权限管理、资产管理、业务风控及供应链问题。

主要变化如下图所示：

img

PPT绘制，变化分析

  1. 针对身份认证漏洞，越来越多的服务提供商开始将身份认证范围从对人的认证变为对“人+机”的认证。这意味着除了对用户身份进行验证外，还需结合设备、环境等其他因素来进行身份认证。这种方式相比传统的单一身份认证方式更安全可靠，可以有效避免伪造、冒用等攻击手段。
  2. 增加了“服务端请求伪造漏洞”内容，说明这是一种非常危险的安全漏洞，攻击者可以利用该漏洞窃取敏感信息、发起内网攻击、进行DoS攻击等，同时表明了在服务端请求处理过程中，输入验证与过滤的重要性。加强对SSRF漏洞的防范，可以有效提高应用程序的安全性。
  3. 随着人工智能、机器学习等技术的发展，自动化攻击手段也变得越来越普遍和复杂。自动化攻击可以通过机器学习算法、大数据分析、自动化工具等方式，快速、准确地扫描目标系统漏洞或发起攻击，对系统造成严重威胁。增加了“缺少对自动化威胁的防护”内容，说明在实际应用中，很多企业缺乏对自动化攻击的防护措施，存在一定的安全风险。而不安全的第三方API可能会导致系统遭受攻击，企业需要加强安全意识，选择可信赖的服务提供商，进行充分的安全测试和验证，限制API的权限并监控API的使用情况，可以保障系统的安全性。

这些趋势变化说明了在信息化和数字化快速发展的时代，传统的身份验证方式已经无法满足日益增长的安全需求，需要采用更多元化、智能化的身份认证方式来提高系统、服务、数据的安全性。

OWASP API安全10大变化2023RC

Open Web Application Security Project (OWASP) 基金会通过由社区主导的开放源代码软件项目、全球数百个分会、数万名会员，以及通过举办地方和全球会议，致力于提高软件安全性。OWASP API安全项目旨在通过强调不安全API中的潜在风险，并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API安全项目将创建并维护一份10大API安全风险文档，以及创建或评估API时最佳实践的文档门户。

最近，OWASP API项目决定更新流行的API安全前十威胁地图。Salt Security团队一直积极参与该项目，是最初创建该列表的重要贡献者之一。我们继续深入参与思考过程、数据收集和更新方案的头脑风暴。

截至本文撰写时，API安全前十2023的最终版本尚未正式发布。然而，一个初始的发布候选版本已经发布。在这篇文章中，我们想分享一些这个新API安全前十地图背后的动机，并分享我们的观点以及一些数据，以支持这些决策。

一、API1:2023 破损的对象级别授权（BOLA）

1.1 定义

BOLA攻击向量在映射【map】中保持着其尊重的第一名位置，并且理所当然。在API攻击中，BOLA攻击仍然是首选攻击向量。

BOLA保持最高排名的主要原因是所有形式的API中复杂和多样的授权机制（或缺乏授权机制）。虽然一些API框架允许更好的授权控制，但其他框架则没有。在快速开发的环境中，监督每个授权问题和检查每个对象的访问权限以确保只有允许的用户可以访问它变得非常困难。

另一方面，由于授权是每个系统的核心，一旦错误实施，授权失败可能会产生灾难性的影响，就像我们最近发现的那个例子一样。研究人员在各种汽车制造商提供的在线服务中发现了几个BOLA漏洞。在这个例子中，攻击者可以利用BOLA漏洞接管任何法拉利车主的在线账户，并代表其执行任何操作。

BOLA:

1.2 场景

BOLA案例: Web Hackers vs. The Auto Industry: Critical Vulnerabilities in Ferrari, BMW, Rolls Royce, Porsche, and More

在线商店（商店）的电子商务平台提供了一个列表页面，其中包含其托管商店的收入图表。通过检查浏览器请求，攻击者可以识别用作这些图表数据源的API端点及其模式/shops/{shopName}/revenue_data.json。使用另一个API端点，攻击者可以获得所有托管店铺名称的列表。通过一个简单的脚本来操作列表中的名称，替换URL中的{shopName}，攻击者可以访问数千家电子商务商店的销售数据。

1.3 缓解方式

  • 实现适当的授权机制，该机制依赖于用户策略和层次结构。
  • 在使用客户端输入访问数据库中的记录的每个函数中，使用授权机制检查登录的用户是否有权对记录执行请求的操作。
  • 更喜欢使用随机和不可预测的值作为记录ID的GUID。
  • 编写测试以评估授权机制的漏洞。不要部署导致测试失败的更改。

常见的授权机制？

二、API2:2023 破损的身份验证（Broken Authentication）

2.1 定义

紧随BOLA和授权问题之后的是身份验证问题，它们保持了第二高的攻击向量排名。

在身份验证情况下，相对于授权情况，有更多标准（和非标准）选项可用于执行该功能。由于身份验证流程的敏感性，该过程中的任何小问题可能会对安全性产生严重影响，而每种身份验证方法都引入了其自己的一系列可能问题，使得保护它们成为一项非常复杂的任务。

一个这样的例子可以在Salt Labs最近发布的研究中看到，在该研究中，booking.com的社交登录功能不当，可能导致攻击者接管该网站数百万用户中的任何一个账户。

2.2 场景

booking.com的社交登录功能不当

2.3 缓解方式

三、API3:2023 破损的对象属性级别授权（Broken Object Property Level Authorization）

3.1 定义

这个新类别处理对象属性级别授权，与对象级别授权（API-1）相对。

这个新类别的主要思想是，即使一个特定的API可以实施足够的对象级别授权安全措施，它可能仍然不足够。通常，授权需要更加细粒度，并包括对象及其属性。很常见的情况是，API对象具有一个公共属性和一个私有属性，这些不同的访问级别也必须得到处理。

从更具体的角度来看，虽然这个类别是新的，但它将2019年的两个旧类别合并为一个。这些类别包括“过度数据暴露”和“大规模分配”，很好地符合这个新定义。

3.2 场景

Twitter报告的最近一起事件展示了这个类别对即使是最大的、经过良好审查的服务所构成的风险。在这种情况下，攻击者可以通过提供电子邮件地址或电话号码并检查返回的错误响应来枚举现有的Twitter用户。对于现有用户，一个特定的错误消息属性以确定的方式被改变，从而允许这个枚举过程的发生。

案例分析：影响推特上某些帐户和私人信息的事件

场景一

在基于短视频的社交网络中，有一些限制性内容需要进行过滤和审查。即使上传的视频被系统拦截了，用户还是可以通过以下API请求来修改视频的描述信息。

1
2
3
PUT /api/video/update_video
{"description":"a funny video about cats"}
{"description":"a funny video about cats","blocked":false}

这就意味着，如果用户上传不良内容的视频并通过修改描述信息的方式绕过系统审查。

四、API4:2023 无限制的资源消耗（Unrestricted Resource Consumption）【Dos】

4.1 定义

虽然类别名称可能有些变化，描述也有所改变，但该类别整体上保持不变。

资源是任何API的心脏和灵魂，没有它们，API将仅仅是一个空壳。而且，虽然你不能没有资源，但与资源共存会带来安全风险。资源的消耗可能会迅速导致许多种DoS场景，无论服务器是否处理巨大文件（从而消耗其CPU资源），过多的流量（消耗网络资源）或任何其他类型的资源消耗。

这些攻击的流行主要源于执行此类攻击通常非常简单，有时仅需将大文件上传到文件上传端点即可。另一方面，成功的攻击很快就能导致DoS情况，这可能正是攻击者想要实现的效果，无论是作为攻击本身还是为其他类型的攻击制造烟幕。

这种攻击的一个非常流行的例子是针对API的DDoS攻击。这些攻击通常非常嘈杂，因此经常引起公众的关注。最近的一个例子显示，由于此类攻击，波兰的关键税收门户对波兰公民不可用。

4.2 场景

DOS案例：Poland Points Finger at Russia Over DDOS Attack on Nation’s Key Tax Portal

4.3 缓解方式

五、API5:2023 破损的功能级别授权（Broken Function Level Authorization）

5.1 定义

这个类别保持了它在2019年的排名，并且仍然是最受欢迎的API攻击方法之一。

这个问题的来源可能会有所不同，可能是由于缺乏API的适当文档（这在所有API从业者中非常常见），也可能是由于使用CI/CD和类似方法的快速开发周期。

攻击发生在特定的API端点有一个相邻的端点使用不同的HTTP方法（REST），未经记录的突变（GraphQL），甚至是不同的编码。这些“隐藏”的端点具有特定的功能，通常不应该向公众公开。如果这样的功能可以作为攻击的一部分被发现有用，攻击者可能会执行未知或非特权操作，以帮助他们的攻击。

这种情况的一个例子是Reddit漏洞，允许用户使用“隐藏”的PATCH端点绕过所有广告内容限制，而不需要Reddit的任何同意即可批准广告。

5.2 场景

案例分析：Why this SIMPLE mistake earned a $5000 bug bounty from Reddit

5.3 缓解方式

六、服务器端请求伪造（“SSRF”）

https://github.com/OWASP/API-Security/blob/master/2023/en/src/0xa6-server-side-request-forgery.md

6.1 定义

2023年新增的一个非常恰当的类别是服务器端请求伪造（“SSRF”）。

当用户控制的URL通过API传递并被后端服务器接受和处理时，就会发生SSRF。如果后端服务器试图连接用户提供的URL，SSRF的门立即打开，环境的风险变得真实。

SSRF可能有许多不同的类型和风格。一些常见的情况可能包括：

  • 后端服务器连接到外部攻击者控制的域，并在这样做的过程中可能会暴露内部凭据，这些凭据可以用于升级攻击。
  • 后端服务器在各种TCP端口上连接到其回环接口，允许攻击者在后端服务器上执行端口扫描服务发现。
  • 后端服务器连接到其他内部服务，否则攻击者无法访问，扩大了可用的攻击面，并为其他链接的攻击向量打开了大门。

6.2 场景

Salt Labs最近发布的研究突出了SSRF攻击中嵌入的风险。在这项研究中，Salt Lab的研究人员能够访问巨型乐高拥有的网站的内部网络资源，从而可能危及这个著名Web服务支持的整个外围防御机制。

SSRF案例分析：缺失的积木：寻找乐高 API 中的安全漏洞

场景一：

社交网络允许用户上传个人资料图片。用户可以选择从他们的机器上传图像文件，也可以提供图像的URL。选择第二个将触发以下API调用：

1
2
3
POST /api/profile/upload_picture

{"picture_url":"http:///example.com/profile_pic.jpg"}

攻击者可以发送恶意URL，并使用API端点在内部网络内启动端口扫描。

1
{"picture_url":"localhost:8080"}

根据响应时间，攻击者可以判断端口是否打开。

场景二：

安全产品在检测到网络中的异常时会生成事件。一些团队更喜欢在更广泛、更通用的监控系统中审查事件，例如SIEM（安全信息和事件管理）。为此，该产品使用webhook提供与其他系统的集成。

作为创建新webhook的一部分，将使用SIEM API的URL发送GraphQL变异。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
POST /graphql

[
  {
    "variables": {},
    "query": "mutation {
      createNotificationChannel(input: {
        channelName: \"ch_piney\",
        notificationChannelConfig: {
          customWebhookChannelConfigs: [
            {
              url: \"http://www.siem-system.com/create_new_event\",
              send_test_req: true
            }
          ]
    	  }
  	  }){
    	channelId
  	}
	}"
  }
]

在创建过程中，API后端向提供的webhook URL发送测试请求，并向用户显示响应。

攻击者可以利用此流，使API请求成为敏感资源，例如公开凭据的内部云元数据服务：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
POST /graphql

[
  {
    "variables": {},
    "query": "mutation {
      createNotificationChannel(input: {
        channelName: \"ch_piney\",
        notificationChannelConfig: {
          customWebhookChannelConfigs: [
            {
              url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\",
              send_test_req: true
            }
          ]
        }
      }) {
        channelId
      }
    }
  }
]

由于应用程序显示来自测试请求的响应，因此攻击者可以查看云环境的凭据。

6.3 缓解措施

  • 隔离网络中的资源获取机制：通常这些功能旨在检索远程资源，而不是内部资源。
  • 只要可能，请使用的允许列表
    • 远程源用户应从（例如Google Drive、Gravatar等）下载资源
    • URL方案和端口
    • 给定功能的可接受媒体类型
  • 禁用HTTP重定向。
  • 使用经过良好测试和维护的URL解析器来避免URL解析不一致所引起的问题。
  • 验证并清除所有客户端提供的输入数据。
  • 不要向客户端发送原始响应。

七、API7:2023 安全配置错误（Security Misconfigurations）

7.1 定义

安全配置错误保持其排名，成为最受欢迎的API攻击向量之一。

当然，安全配置错误是一个更广泛的类别，适用于许多其他主题，而不仅仅是API。然而，由于API通常是设计在底层基础架构之上的，它可能是一个简单的HTTP服务器或一个【闪亮】的API网关。这些基础设施组件必须进行适当的配置。在这个配置中的任何错误可能会威胁整个API及其所有端点的安全。

一个非常简单但常见的情况是API缺乏适当的SSL定义，导致所有请求都通过HTTP而不是HTTPS发送，这将允许中间人攻击向量的发生。

Wiz安全研究团队发现的最近漏洞展示了这些安全问题可以有多么严重。在攻击链的某个点上，研究人员可以访问内部IBM云k8s API，这使他们能够进一步升级他们的攻击，最终读取和修改存储在其租户的PostgreSQL数据库中的数据。

7.2 场景

案例分析：Hell's Keychain：IBM Cloud Databases for PostgreSQL 中的供应链漏洞允许潜在的未经授权的数据库访问

7.3 缓解方式

八、API8:2023 缺乏对自动化威胁的保护（Lack of Protection from Automated Threats）

Attack vectors Security Weakness Impacts
可利用性 3 普及率3：可检测性1 技术1：特定于业务
利用通常包括理解API的业务模型，查找敏感的业务流，并自动访问这些流，从而对业务造成危害. 当被分解时，每个攻击请求都代表一个完全合法的请求，不能被识别为攻击。只有在查看与服务/应用程序业务逻辑相关的请求总数时，才能识别攻击。 一般来说，预计不会产生技术影响。剥削可能会以不同的方式损害业务，例如：1。阻止合法用户购买产品；2.导致游戏内部经济的通货膨胀；3.允许攻击者发送过多的消息/评论，并容易传播假新闻。

8.1 定义

这个新类别聚焦于一种新型常见的API攻击类型，主要解决业务逻辑流被滥用以允许恶意行为的场景。

尽管这些攻击是常见的，但它们极难检测和防御。在这个攻击类别中，攻击本身是一组请求的总和的衍生物，其中每个单独的请求是完全合法的。只有在特定的业务逻辑上下文中查看API请求的总和时，攻击才会显露出来。

这个类别出现在所有业务部门中，每次攻击对于每个环境和每个业务逻辑都是完全独特的。检测这些攻击只能通过查看整体用户/请求流程来进行，逐个检查每个请求将永远不会揭示攻击。

8.2 场景

最近发表的研究显示，研究人员如何通过执行自动化攻击来滥用URL缩短服务及其业务逻辑。通过执行这次攻击，研究人员可以接管使用URL缩短器服务的公司的帐户。

案例分析：Abusing URL Shortners for fun and profit

场景一：

一家科技公司宣布，他们将在感恩节发布一款新的游戏机。该产品的需求量很大，库存有限。攻击者，自动威胁网络的操作员，编写代码自动购买新产品并完成交易。

在发布当天，攻击者运行分布在不同IP地址和位置的代码。API没有实现适当的保护，允许攻击者在其他合法用户之前购买大部分股票。

后来，攻击者在另一个平台上以高得多的价格出售该产品。

场景二：

拼车应用程序提供了一个推荐计划，用户可以邀请他们的朋友，并为每个加入该应用程序的朋友获得积分。这笔贷款以后可以用作现金预订乘车服务。

攻击者通过编写脚本来自动化注册过程，并让每个新用户向攻击者的钱包添加信用，从而利用此流。攻击者稍后可以享受免费乘车服务，或者将信用额度过高的账户出售以换取现金。

8.3 缓解措施

缓解规划应分两层（业务+工程）进行：

  • 业务-识别如果过度使用可能会损害业务的业务流。
  • 工程-选择正确的保护机制来降低业务风险。有些保护机制更为简单，而另一些则更难实施。以下方法用于减缓自动威胁的速度：
    • 设备指纹识别：拒绝向意外的客户端设备（如无头浏览器）提供服务往往会使威胁行为者使用更复杂的解决方案，从而使他们的成本更高
    • 人体检测：使用captcha或更先进的生物识别解决方案（例如打字模式）
    • 非人模式：分析用户流以检测非人模式（例如，用户在不到一秒钟的时间内访问了“添加到购物车”和“完成购买”功能）
    • 考虑阻止Tor出口节点和已知代理的IP地址；
  • 安全并限制对机器直接使用的API（如开发人员和B2B API）的访问。它们往往很容易成为攻击者的目标，因为它们通常无法实现所有所需的保护机制。a

九、API9:2023 不当的库存管理（Improper Inventory Management）

9.1 定义

随着越来越多的公司暴露出许多API，以及频繁发布新的API端点，组织、监视、发现和获得更多对发布的API的可见性的挑战成为一个非常大的问题，许多组织发现很难适当地处理它。

与此类别相关的一些非常常见的攻击场景将是攻击者可以找到一个“弱”端点或API并滥用它的情况。弱点的例子包括错误地向公众公开的测试或开发API，这些API可能没有包括在生产API中的所有安全措施。

9.2 场景

Optus数据泄露是这个类别的一个完美例子，澳大利亚第二大电信公司Optus因一个“被遗忘”的API向公众暴露了超过1120万个客户记录，其中包含数十个PII信息。公司已经拨出了1.4亿澳元来支付此次泄露的成本。

案例分析：Optus Data Breach – Why Vulnerable APIs are to Blame

十、API10:2023 不安全的API消费

10.1 定义

新的不安全消费类别包含两个常见的API问题。其中一个问题是解决API数据本身的消费。这个类别不是新的，其中大部分已经包含在OWASP API-8 2019（注入）部分中，可以通过API执行许多类型的基于注入的攻击。

这个新的2023类别将这种类型的攻击扩大到包括不明确与注入相关的攻击，例如反序列化问题、某些类型的脱节攻击等。所有这些攻击的共同根源是后端服务在接受通过API传递的用户控制输入时过于宽容，有时甚至盲目地使用它们而没有应用任何适当的验证。

也许最好、最近、最相关的例子是臭名昭著的Log4Shell攻击，这场攻击引起了整个互联网的严重震荡，允许用户在几乎每个使用非常流行的Log4j日志库的Web服务上运行任意代码，使用简单执行的JNDI注入技术。

第二个问题密切相关，涉及到另一种攻击，滥用了几乎每个现代系统设计中的一个薄弱环节——集成。集成可以包括任何嵌入到API实现或其支持的后端服务中的第三方服务或功能。

第三方通常编写集成，其中包含大量的代码库，往往非常复杂，很难理解代码的内部运作方式。然而，将它们应用到您自己的服务通常只需要几个点击或几行代码。

可能会出现非常高风险的情况，其中服务包含大量未经验证的代码——从安全角度来看未经验证的代码。其中一些或全部直接与核心服务逻辑交互。这种风险是一个臭名昭著的攻击面，是攻击者在寻找漏洞时的首选之一。

10.2 场景

虽然不是专属于这个类别，但基于API的供应链攻击是这个类别危险的一个很好的例子。在这项最近的研究中，安全研究人员发现通过攻击第三方WordPress和Magento插件的妥协执行的恶意活动，影响了选择使用这个第三方集成而没有进行适当安全验证的任何实现。

总结

从以上最新的API Security Top 10（候选版），可以看到，现在API安全和传统的Web安全有很大区别，一方面需要在设计和开发阶段，对API的安全性进行良好的构建和设计；另一方面还需要在进入运维阶段后，针对API进行专项型的防护，根据API的特点构建全生命周期的防护体系，从而更好地应对各类风险，做到未雨绸缪、防患于未然。

参考文献

我们鼓励整个安全社区进一步探索新的发布候选版本——这是您分享想法、评论甚至反对该项目的机会。

  • https://github.com/OWASP/API-Security
  • https://owasp.org/www-project-api-security/
  • https://github.com/OWASP/API-Security/tree/master/2019/en/src
  • OWASP API 安全性 Top 10 2023RC 的主要变化：https://salt.security/blog/top-changes-in-the-owasp-api-security-top-10-2023rc?
  • SSRF（Server-Side Request Forgery）：https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
  • Azure：使用 API 管理缓解 OWASP API 安全性十大威胁的建议：https://learn.microsoft.com/zh-cn/azure/api-management/mitigate-owasp-api-threats
  • 星阑科技：OWASP API Security Top 10 (2023-RC更新)：https://www.freebuf.com/articles/neopoints/365201.html
  • Neosec 涵盖每个 OWASP API 前 10 大漏洞
  • BOLA 攻击剖析——第 1 部分：https://www.neosec.com/blog/anatomy-of-a-bola-attack-part-1