什么是 API 安全?

应用程序接口安全是指保护应用程序接口(API)免受恶意使用或试图利用 API 来窃取敏感数据或破坏服务的攻击。应用程序接口安全采用各种策略、技术和解决方案,确保只有经授权的用户才能访问和使用应用程序接口,并确保通过应用程序接口传输的数据不受未经授权的访问或篡改。

 

应用程序接口安全说明

由于应用程序接口是系统和服务的后端框架,因此确保应用程序接口的安全至关重要,以保护其传输的敏感数据,包括访问信息,如身份验证、授权、输入验证和加密。应用程序接口安全指的是旨在保护这些后端框架并减少来自违规访问、僵尸攻击和滥用的攻击的方法和工具。

常见的 API 攻击类型

  • 拒绝服务 (DoS) 攻击
  • 分布式拒绝服务 (DDoS) 攻击
  • 中间人(MITM)攻击
  • 破坏访问控制攻击
  • 注射

成功的 API 攻击会导致大量数据丢失、私人或个人信息被盗以及服务中断。

 

应用程序接口的定义

API 是应用程序接口的缩写,由一系列定义和协议组成,允许软件组件进行通信。作为软件系统之间的中介,API 使软件应用程序或服务能够共享数据和功能。但应用程序接口不仅仅是提供连接基础设施。它还规定了软件应用程序的通信和交互方式。应用程序接口(API)控制着程序之间交换请求的类型、发出请求的方式以及允许的数据格式。

应用程序接口允许组织与客户和其他外部用户共享数据。应用程序接口的类型包括用于支付处理、视频会议、社交媒体、短信、医疗或健身监控以及智能家居的应用程序接口。Rest API 可以是开放的或封闭的,公共的或私有的,通常符合 REST、SOAP 或 GraphQL 等架构标准。

应用程序接口还能让开发人员访问其他应用程序的功能,从而减少重复构建新连接基础设施的需要,甚至不需要了解其底层代码或架构。

图 1:现代应用结构
图 1:现代应用结构

 

API 安全为何重要

应用程序无处不在,是商业和社会不可或缺的一部分。而几乎每个应用程序背后都有一个应用程序接口,这使得应用程序接口的安全性变得至关重要。

API 是大多数云原生应用程序(包括移动应用程序、网络应用程序和 SaaS 以及面向内部、合作伙伴和客户的应用程序)的后端框架。从 API 使用的角度来看,API 管理平台 Postman 在 2022 年的 API 调用次数 达到 11.3 亿次 。当然,随着应用程序接口的兴起,潜在的有利可图的攻击面也在诱惑着不良行为者。

由于应用程序接口暴露了应用逻辑、资源和敏感数据(包括个人身份信息 (PII)),它们已成为攻击者的目标。如果攻击者能够访问未受保护的应用程序接口,他们就可能扰乱业务、访问或破坏敏感数据并窃取财产。

图 2:利用应用程序接口的现代微服务应用程序
图 2:利用应用程序接口的现代微服务应用程序

 

网络应用程序安全的传统方法

单体应用时代的网络应用安全包括在外围部署 网络应用防火墙(WAF) ,以拦截和检查网络客户端发送的 HTTP 流量。当应用程序面临的潜在风险主要涉及嵌入在标准 HTTP 网络表单提交或浏览器请求中的恶意用户输入时,WAF 可提供并持续提供有效的应用程序安全性。

但是,网络应用程序的性质已经发生了变化,从由单个网络服务器托管的单体应用程序变成了分布在主机服务器集群上的容器化云原生应用程序。

今天的开发人员和安全小组--处理高度分布式的云原生微服务架构--必须与无边界网络作斗争。现代应用程序消耗的输入来源广泛,包括标准 Web 请求、移动设备 API 调用、云事件、IoT 设备遥测通信、云存储等。

客户端的 HTTP 入站请求(即南北向流量)往往是一连串通信流中的第一个。在许多情况下,一个入站请求会产生几十个内部 API 调用(即东西向流量)。如果不对这些内部 API 调用进行适当的检查和验证,API 端点就会失去保护。

在外围检查输入不足以捕捉到危险的有效载荷。内部 API 端点可能配置错误,允许未经授权访问单个微服务,从而将应用逻辑暴露在恶意操作之下。对所有 API 端点(外部和内部)进行持续监控并确保其安全至关重要。


视频API 安全性概述和增强 API 安全性的技巧

 

API 攻击剖析

随着组织依赖应用程序接口来推动业务发展,攻击者也在四处寻找可利用的应用程序接口漏洞。这个针对以移动应用程序为前端的电子商务应用程序的 API 攻击示例说明,威胁参与者可以轻而易举地找到获取有价值数据的途径。

图 3:基于应用程序接口的攻击剖析
图 3:基于应用程序接口的攻击剖析

步骤 1:通过逆向工程移动应用程序,攻击者发现了用于从后端微服务检索数据的已废弃 API 端点 URL。

步骤 2:攻击者注意到,向该端点发送 API 调用既不要求身份验证,也不要求授权。

步骤 3:攻击者滥用 SQLi 漏洞。API 端点 URL 以数值的形式提供了唯一的产品标识符,攻击者运行一系列自动检查后发现,输入字段<product_id> 可被利用来成功实施 SQLi 攻击。

步骤 4:攻击者没有滥用 SQLi 来篡改数据,而是选择滥用 SQLi 漏洞,在运行 SQL 数据库的微服务中运行 shell 命令。shell 命令会下载恶意可执行文件并执行。该可执行文件是一个比特币挖矿软件。

 

应用程序接口安全风险

应用程序接口配置错误、逻辑缺陷和漏洞使应用程序和数据暴露在攻击者面前。虽然 API 网关只能看到通过网关路由的 API 流量,并不能提供内部流量的可见性,但一些组织还是将其 API 安全性归咎于 API 网关,认为它能提供全面的 API 保护。

安全小组需要了解整个 API 表面的情况。你无法保护你看不到的东西,而你看不到的东西最终会成为发现影子应用程序接口的不良行为者未被发现的活动。

虽然 API 网关能有效监控 API 和 API 的使用情况,但却无法检测和阻止攻击。应用程序接口安全要求实时防范恶意攻击--此外还有可视性和风险管理。

OWASP 10 强

开放网络应用安全项目(OWASP)于 2019 年发布了一份 API 安全十大风险 清单,以提高人们对影响现代网络应用的 API 安全风险的认识。本列表概述了针对网络 API 的最常见攻击,并包含保护您的 API 免受这些威胁的提示。

被破坏的对象级授权

处理对象标识符的端点经常被应用程序接口暴露出来,从而导致级别访问控制问题,扩大了攻击面。例如,如果没有实施适当的授权检查,攻击者就可能在 API 调用期间替换属于其他用户的资源 ID。这种攻击被称为不安全直接对象引用 (IDOR),它允许攻击者访问未授权访问的资源。

破损的用户身份验证

API 身份验证机制很容易成为攻击目标,因为它们暴露在所有人面前。实施不力的身份验证机制被称为 API 身份验证漏洞,它给攻击者提供了入口,攻击者可以利用实施缺陷冒充授权用户的身份。

如果绕过行业最佳实践,如未实施访问令牌验证或在 API 端点 URL 中存储凭证和密钥,就会发生 API 身份验证配置错误。

过度数据暴露

暴露的数据越多,风险就越大。在应用程序接口实施过程中,开发人员有时会暴露对象属性而不逐项限制,并依赖客户端在用户界面显示之前过滤掉不必要的数据。但是,即使应用程序接口客户端过滤掉了敏感数据,攻击者仍然可以利用最初的应用程序接口调用,并可能获取信用卡号、登录凭证和社会安全号。

缺乏资源和速率限制

不限制客户端可调用资源数量的 API 很容易因流量超载而被滥用。这种过载会降低 API 服务器的性能,锁定合法用户,甚至导致 DoS。应用程序接口服务器超载也会使应用程序接口受到验证漏洞(如暴力验证)的威胁。

破损的功能级授权

应用程序接口开发人员面临的挑战之一是为不同层次的用户组和角色实施访问控制策略的复杂性。管理功能和常规功能之间的模糊区别造成了授权漏洞,攻击者可以利用这些漏洞访问用户的资源或执行未经授权的管理功能。

大规模分配

当客户提供的数据绑定到数据模型时,没有根据白名单进行过滤,以防止用户将数据分配到受保护字段时,就会出现大量分配漏洞。利用这个漏洞,攻击者可以通过拦截 API 查询,并通过猜测对象属性、阅读文档和搜索 API 端点来获取如何破坏私有 API 数据属性的提示,从而更改存储的后端对象属性,从而获取敏感数据。

安全配置错误

安全配置错误会暴露敏感的用户信息和系统细节,有可能导致服务器受损。常见原因包括许可的跨源资源共享(CORS)、不完整或临时配置、不正确的 HTTP 标头或 HTTP 方法、不安全的默认配置、不完整或不正确的配置,以及暴露敏感信息的冗长错误信息。

注射

应用程序接口存在注入漏洞--SQL 注入、NoSQL 注入和命令注入--当不受信任的数据作为命令或查询的一部分被发送到解释器时,这些漏洞就会发生。攻击者可以诱使解释器执行危险的命令,从而暴露未经授权的数据,使其被篡改和窃取。

资产管理不当

与传统网络应用程序相比,应用程序接口暴露了更多的端点,而跟踪这些端点的强大应用程序接口管理对于防止滥用已暴露的敏感或脆弱应用程序接口端点至关重要。例如,过时的 API 端点或调试端点可能会被攻击者用来入侵应用程序。

日志记录和监控不足

日志记录和监控不足虽然不是直接威胁,但会延误对恶意活动的检测。不良分子在黑暗中行动,有充足的时间推进攻击,并向不同的系统发展,以篡改、提取和破坏数据。根据漏洞研究,对持续威胁的检测可能需要 200 天以上的时间。而在发生数据泄露后,如果没有适当的日志记录和监控,组织就会缺乏取证信息来评估损失。


视频了解 OWASP、AppSec 和 OWASP 十大应用程序安全风险

 

SOAP、REST 和 GraphQL 的 API 安全性

SOAP、REST 和 GraphQL 是三种常见的 API 架构模式,每种 API 架构风格都有不同的安全考虑因素。

SOAP API 安全

SOAP(简单对象访问协议)是在计算机网络中实施网络服务时交换结构化数据的一种协议。SOAP 使用 XML 作为信息格式,可通过各种低级协议(包括 HTTP 和 SMTP)传输。SOAP 应用程序接口通常结合使用传输层安全(如 HTTPS)和消息层安全(如 XML 数字签名和加密)来确保安全。

SOAP API 安全性涉及处理安全问题的协议扩展。SOAP 遵循网络服务(WS)规范,通过 WS-ReliableMessaging 等功能(扩展了内置错误处理支持)确保所有网络服务的企业级安全性。

REST API 安全性

表征状态传输 API(或称 REST API)的架构依赖于 JSON 数据传输和 HTTP/S 传输协议,与其他 API 架构相比,两者都简化了 REST API 的开发。Rest API 使用 HTTP 请求来 POST(创建)、PUT(更新)、GET(读取)和 DELETE(删除)数据。

由于缺乏内置的安全配置,REST API 的安全性取决于 API 的设计。数据传输、部署和客户端交互服务必须考虑到安全因素。大多数 RESTful API 将依赖传输层安全(如 HTTPS)和基于令牌的身份验证。

解决 REST API 安全问题的一种常见架构选择是在 API 网关后面部署 REST API,然后向客户端提供这种连接选项。不过,API 网关并不具备抵御各种安全威胁的能力。

REST 与 SOAP

SOAP 和 Restful API 支持 HTTP 请求和响应,以及安全套接字层(SSL),但共性仅此而已。SOAP 应用程序接口具有内置安全功能,本质上是安全的。相比之下,RESTful API 必须通过实施和架构选择来确保安全。

GraphQL API 安全

GraphQL 是一种开源 API 语言,它既能描述客户端如何请求信息,又能作为运行时来实现对现有数据的查询。开发人员使用 GraphQL 语法从单个或多个来源提出特定的数据请求。利用 GraphQL,客户可以定义请求的数据结构,而服务器将确保返回准确的结构。

执行 GraphQL API 安全性带来了与可定制和灵活请求相关的挑战。服务器可能无法处理复杂的查询,并可能在此过程中无意中执行恶意查询。

降低 GraphQL API 安全风险的方法包括节流、设置最大查询深度以及查询超时,以防止大查询。

 

应用程序接口安全最佳实践

随着越来越多的应用程序接口被公开使用,通过实施最佳实践来最大限度地减少攻击面、修复漏洞并近乎实时地抓捕恶意活动,从而应对数据暴露的风险就显得尤为重要。

使用安全的身份验证和授权方法

确保只有经授权的用户才能使用安全的身份验证方法(如 OAuth2 或 JSON 网络令牌 (JWT))访问应用程序接口。

实施速率限制

对 API 实施速率限制,以防止暴力攻击和其他恶意行为。速率限制可限制在指定时间内向应用程序接口发出的请求数量。

使用 HTTPS

应用程序接口的请求和响应应使用 HTTPS,以确保其加密和安全。在处理敏感数据时,这一点尤为关键。

定期进行安全评估

定期评估 API 的安全性,找出潜在漏洞。审查 API 清单的变化,检测新暴露的 API 及其风险概况,包括敏感数据暴露、互联网暴露、 工作负载漏洞 和身份验证级别。

使用 API 密钥

API 密钥是唯一的标识符,用于识别调用 API 的应用程序并验证访问授权。API 密钥与身份验证令牌的不同之处在于,它们识别的是进行 API 调用的应用程序(或网站),而不是使用该应用程序(或网站)的人。两者都是重要的安全措施。

遵循 API 密钥存储最佳实践,避免不必要的呼叫、未经授权的访问和潜在的数据丢失。

监控您的应用程序接口

管理和监控应用程序接口规范、文档、测试用例、流量和指标。阻止不必要的活动,如恶意 API 流量和恶意机器人,以帮助保护应用程序并降低不必要的成本。

向安全小组传授最佳安全实践方法

尽早将安全嵌入 CI/CD 管道 ,并提供培训以提高开发人员对安全风险的认识,如弱身份验证和逻辑漏洞。实施 DevSecOps 原则,包括安全小组与开发小组之间的协作。

了解你的弱点

通过定期查找 OWASP API 安全十大风险,找出 API 生命周期中的薄弱点。使用 API 扫描工具和技术识别每个 API 漏洞,并立即解决以防止漏洞被利用。

要求使用安全令牌进行身份验证

要求使用安全令牌进行身份验证是第一道防线。安全令牌可在用户的令牌验证失败时拒绝 API 调用,从而保护 API 免遭未经授权的访问。

简而言之,最佳实践应从对攻击面的可见性和监控开始,它可以自动发现环境中的所有网络应用程序和 API 端点。防御层应包括南北向和东西向流量策略,以阻止恶意威胁,无论它们来自互联网还是应用程序内部。

再增加一层漏洞和合规性扫描以及强大的身份验证功能,将进一步保护您的应用程序。您还需要确保工作负载或基础设施层的安全,例如帮助托管应用程序的主机、虚拟机、容器和无服务器功能。

 

Prisma 云的 API 安全解决方案

Prisma Cloud 为所有 API 提供完整的 API 发现、风险分析和实时保护,这是其全面的云原生应用程序保护平台 (CNAPP)的一部分。

应用程序接口安全功能

  • API 发现:自动发现环境中的所有 API,消除阴影或恶意 API 造成的盲区。
  • API 风险分析:识别 API 风险和风险因素(如配置错误、暴露于敏感数据和访问控制),并优先进行补救。
  • 实时保护:针对 API、速率限制和恶意机器人等 OWASP Top 10 攻击实施实时保护。

 

应用程序接口安全常见问题

单体应用程序是作为一个独立单元构建的,独立于其他计算应用程序,其大部分或全部功能都在一个进程或容器中。软件程序传统上被设计为单体应用程序,包括分层在软件应用程序中的所有要求组件--应用程序接口、服务、数据访问、数据库等。这样设计的单体应用程序可以执行完成任务所需的所有功能,从获取用户输入到处理数据并将数据存储到数据库中。
面向服务的体系结构指的是一种软件设计,应用组件通过网络传输的通信协议向其他组件提供服务或数据交换。

微服务架构包括将应用程序的功能划分为模块化组件。应用程序由松散耦合的微服务构成,通过轻量级协议进行通信。

松散耦合的微服务使开发人员能够以相对轻松的速度创建复杂的应用程序。这种云原生架构还能跟上客户需求不断变化的步伐,因为微服务的解耦特性允许开发人员更频繁地推送新代码和新功能,而不是像以前那样。

SOAP 是一种使用基于 XML 的轻量级协议在应用程序之间交换信息的方法。虽然 SOAP 消息通常通过 HTTP 会话传输,但只要客户端和服务器使用相同的方法,就可以按照应用程序的要求发送消息。
传输层安全(TLS)是一种加密协议,用于保护计算机网络和互联网通信。使用 TLS 的常见例子包括 HTTPS、电子邮件和短信。TLS 取代了 SSL(安全套接字层)。
API 端点是 API 中唯一可访问的资源。当应用程序接口与另一个系统交互时,应用程序接口端点就是通信的接触点。这些接触点或端点是应用程序接口访问执行其功能所需资源的位置。由于 API 端点使系统容易受到攻击,因此通过 API 监控防止滥用至关重要。

API 安全测试最适合集成到 DevOps 管道中,它是一种挑战 API 端点安全性的实践,以验证是否合规性安全最佳实践。例如,为了评估身份验证、加密和用户访问条件,应用程序接口要接受故意设计的输入挑战,以仿真不良行为者的攻击载体,从而找出未定义的行为、漏洞和其他漏洞。应用程序接口测试的发现可能包括授权或身份验证绕过、安全配置错误、SQL 和操作系统命令注入以及开源代码漏洞。

应用程序接口安全测试可涉及动态或静态安全测试以及 软件构成分析 (SCA)。SCA 根据 CVE 数据库检查应用程序中的代码。当发现问题时,SCA 工具会提醒开发人员,应用程序或 API 正在使用存在已知漏洞的库或框架。鉴于开放源代码在应用程序接口开发中的广泛使用,软件构成分析在应用程序接口和应用程序安全测试中起着至关重要的作用。

API 网关是一种工具,位于应用程序和一组后端服务之间,充当反向代理,接受 API 调用。API 网关会将每次调用分解成多个请求,并将这些请求路由到相应的服务,每个服务都会产生一个响应,同时 API 网关会跟踪所有活动。
影子应用程序接口(shadow API)也叫僵尸应用程序接口(zombie API),是一种秘密的、无文档记录的、无跟踪的应用程序接口。开发商往往没有意识到它们的存在和特性。
开放式应用程序接口,也称公共应用程序接口,是一种公开的应用程序接口,可为开发人员提供软件应用程序或 Web 界面服务的访问权限。
专用应用程序接口是一种应用程序接口,其应用程序由一个组织托管,作为后台数据和应用功能的前端接口。该界面为授权员工和承包商开发这些功能提供了一个入口点。
DLL 注入是一种利用 Windows 操作系统进程和服务的攻击类型。通过用受感染的版本替换要求的 DLL 文件并将其植入应用程序的搜索参数中,受感染的文件将在应用程序加载时被调用,激活其恶意操作。

网络钩子是一种基于 HTTP 的回调函数,可实现两个应用程序接口之间的事件驱动交互,允许网络应用程序从其他应用程序接收少量数据。但网络钩子不是应用程序接口。它们通常被称为反向或推送 API,因为一旦数据可用,网络钩子就会触发服务器向客户端发送 HTTP POST 请求(而不是接收和响应 HTTP 请求)。应用程序必须有 API 才能使用网络钩子。

在 GitOps 环境中,网络钩子可以触发自动化工作流程,减少实施重 Git 部署管道所需的步骤,包括自动启动 基础设施即代码 工作流程。