浅谈 API 安全

导读：

API 在软件应用体系结构中占有重要的地位。通过在多个服务之间建立通信管道，它们彻底改变了 Web 应用程序的使用方式。随着对全新和颠覆性数字化解决方案的需求不断增长，确保 API 的安全性变得越来越重要。

OWASP 在 2019 年将 API 安全列为未来最受关注的十大安全问题，这种类型的安全漏洞的影响不可低估，API 为网络攻击者提供了危险的入口点。本文将讨论 API 安全性，并分析为什么 API 安全性策略是当今世界应用程序开发生命周期和基础设施的关键部分的一些基本原因以及 API 安全测试的常见手法。

01

什么是 API 安全

API 它的全称是 Application Programming Interface，也叫做应用程序接口，它定义了软件之间的数据交互方式、功能类型。是不同软件应用程序之间进行通信和交互的接口，允许应用程序之间共享数据和功能。

API 安全就是指保护应用程序编程接口（API）免受未经授权的访问、滥用和恶意攻击等的一系列措施和方式。

02

为什么 API 安全很重要

API 是当今数字生态系统的支柱。它们被深度集成到软件系统中，是成功执行应用程序背后的重要驱动力。由于软件行业广泛依赖于 API，因此提供对 API 的访问的组织必须使其更加安全和可信。

如今，典型的 CS(客户端-服务器)应用程序使用 API 交换信息。此外，第三方 API 使用也是将 API 与现有系统集成的一种非常流行的模型。归根结底，这一切都归结为我们如何能够安全地管理此类流程和集成，以提供流畅、透明和可信的用户体验。

除了传统的 CS 或第三方通信之外，API 也在微服务中占有绝对的重要地位，微服务是当今最具创造性和最常用的应用程序架构模型。因此，保护 API 以减少其被攻击的机会，成为企业无法回避的责任。

03

API 分类

● 类库 API：

类库型 API 通常是一个类库，它的使用依赖于特定的编程语言，例如应用程序调用微软基础类库（MFC）。

● 操作系统 API:

操作系统 API 是操作系统层对外部提供的接口，例如，应用程序调用 Windows API 或 Linux 标准库。

● 远程应用 API:

远程应用型 API 是开发者通过标准协议的方式，将不同的技术结合在一起，不用关心所涉及的编程语言或平台，来操纵远程资源。

● Web 应用 API：

Web 应用型 API 通常使用 HTTP 协议，在企业与企业、企业内部不同 的应用程序之间，通过 Web 开发过程中架构设计的方法，以一组服务的 形式对外提供调用接口，以满足不同类型、不同服务消费者的需求。

在 API 技术的发展过程中，业界通常将最初的类库 API 和操作系统 API 称为古典 API，将远程应用 API 和 Web 应用 API 称为现代 API。现代 API 是当前主要采用的 API 技术形式，它们采用了不同的通信协议或消息格式，根据服务对象、技术形式和使用者的不同，可以进行不同类型的分类。

04

API 攻击面

随着针对 API 的攻击日益严重，OWASP 组织推出了 OWASP API Security TOP 10 项目，对目前 API 最受关注的十大风险点进行了总结，以警示业界提高对 API 安全问题的关注。

05

API 安全面临的主要挑战

API 安全事件屡见不鲜，其主要原因是随着 API 的广泛使用，针对 API 的恶意攻击行为愈发增多。然而，作为使用 API 的企业，在 API 生态系统中，却缺乏明确的 API 保护方针和策略。在解决 API 安全风险上，仍面临多个方面的挑战。

◆ API 广泛应用带来的风险面增大

随着互联网上业务种类的不断增加，整体 API 的流量在也增加了很多倍，伴随 API 的广泛使用，API 暴露的攻击面增加，针对 API 的攻击也暴增。

◆ API 安全经验缺失

对于使用 API 技术带来的安全风险，研发人员往往理解不够深入，也缺乏具备丰富安全经验的人员来监督或指导研发过程，导致开发的 API 存在安全漏洞。

◆ 安全合规性挑战

在国家和行业标准的层面上，对于 API 的使用提出了多方面的安全要求。这些标准或规范为企业在 API 安全实践方面提供了指导，同时也为 API 的合规性提供了可操作的标准。

06

API 安全测试 tips

针对 RESTful API：

■ 尽可能多的获取 API 规范描述文件，如在线接口文档、apidocs.json 文件、Swagger 文件，RAML 文件，API-Blueprint 文件等，通过对这些文档的分析来获取 API 的详细调用方式及参数定义。

■ 通过 Proxy 代理，对流量进行分析也是获取 API 信息的一种手段。

■其他可攻击的点，如请求参数、请求方法 GET/POST/PUT/DELETE、是否存在授权绕过（令牌是否正确验证，是否令牌有时效性）、是否存在注入点（MySQL、NoSQL）、是否存在批量分配的问题等。

■ 通用的安全问题，如是否存在 Key 泄露、是否可被暴力破解、同一 API 多个版本不一致问题、XSS、CSRF 等。

■ 面向不同层次会话的攻击，比如传输层是否使用 SSL 或使用可信的数字证书、应用层会话是否设置超时或采取限流熔断机制等。

针对 GraphQL API：

■ 未授权访问问题。正因为“所见即所得”的“客户端请求什么，服务器端会响应什么”的一致性，后端应用程序在应用级的权限访问控制上存在设计错误，导致越权访问或因越权访问导致的敏感数据泄露。

■ 嵌套查询带来的性能问题。如果请求的数据格式嵌套层级过于复杂，对服务器端处理来说会消耗很多资源，这时过多的请求会导致类似 Dos 攻击的行为发生。当然，GraphQL 本身也提供了超时设置、最大查询深度、查询复杂度阈值等安全策略，但在应用程序开发过程中往往存在安全策略设置不当的情况。

■ GraphQL 自身安全配置错误。很多技术组件在使用时官方都会提供相关的安全配置项说明，比如 SpringBoot 安全配置项、Tomcat 的安全基线。GraphQL 虽然没有这些技术组件的配置复杂，但它自身也存在一个管理入口，通常请求路径为/graphql 或/graphql/console/。如果应用程序配置错误，渗透测试人员可以尝试访问/graphql?debug=1，进入调试模式。

针对 SOAP API:

■ XML 类的安全问题在 SOAP API 中比较常见，比如 XML 实体攻击、XPath 注入等。

■ 基于 SOAP API 安全框架实现错误的安全问题，比如针对 WebServices 身份验证的攻击、XML 签名类攻击、针对算法 JWT 的攻击等。导致这些攻击的漏洞有密码在 SOAP 头信息中以明文形式传递 HTTP Basic 认证信息未加密、未对消息进行签名等。

■ 传统的 Web 安全问题仍然存在，比如 SQL 注入、文件上传漏洞、DOS 攻击、重放攻击等。

■ 针对 WSDL 的信息收集或在原 URL 地址后加“?wsdl”可能成为渗透测试的快捷入口。

■ 未授权访问和业务逻辑漏洞也会在 SOAP API 的渗透测试中被发现，常见的导致此攻击的漏洞有未使用身份验证、参数缺少校验或保护导致数据篡改后的权限绕过、敏感数据保护不足等。

07

结语

伴随 API 的广泛使用，传统的安全手段在 API 安全上常常是能力不够的。在安全检测上，传统的漏洞扫描器很难发现 API 或微服务上存在的安全问题。在安全防御上，流量安全防御设备也无法像在常规 Web 防护上发挥很大的防御价值。API 的安全性需要更多的重视，以避免因 API 攻击而造成的业务风险。