如何安全加固API，远离漏洞风险？

本文从 API 的基本概念出发，和您深入探讨与 API 漏洞相关的各种风险，同时通过介绍各种常见的 API 安全实践，以构建出强大的 API 安全机制。

作为一种中介式接口的应用程序编程接口（API），是一组允许软件组件彼此交互的协议。他通常可以将基础架构与运行在其上面的应用程序分离开来，并抽象出系统之间的不同功能。同时，API也能够让软件团队通过重用代码的方式，来简化开发。

随着API在现代业务中的优势和用例的不断增加，由其固有的弱点所带来了各种安全风险也逐渐引起了开发界的重视。下面，我将和您深入探讨与API漏洞相关的各种风险，同时通过介绍各种常见的API安全实践，以构建出API安全机制。

PART 01

什么是API安全性?

作为一组服务，API实现了一个程序与另一个外部、或内部程序之间的通信。在谈论API安全性时，我们通常指的是保护应用程序的后端服务，其中包括数据库、用户管理系统、以及与数据存储交互的其他组件。因此，API安全性常常包含了采用多种工具和实践，来保护技术栈的完整性，进而防止恶意攻击者访问到敏感的信息，或执行各种违规操作。

不幸的是，虽然API是现代应用程序的关键部分，但它们也是攻击者访问敏感信息的常见目标入口。随着API越来越成为攻击的众矢之的，我们有必要在构建API时，了解第三方应用程序是如何通过接口传输敏感数据的，并在此基础上，通过部署API的安全措施，来协助安全团队评估风险，并提高服务的整体安全态势。

PART 02

API漏洞风险

由于API往往是可以被公开访问的，因此它们自然也成为了窃取应用程序逻辑、用户凭据、信用卡号等敏感信息的常见途径。通常，攻击者会利用API端点中的漏洞，以跨站点脚本和代码注入等方式，获得针对目标系统的未经授权的访问、以及其他网络形式的攻击。

目前，业界比较公认的在线Web应用程序安全项目（Open Web Application Security Project，OWASP），针对常见的Web API十大漏洞，发布了基于各类风险的说明与建议。在此，我将和您重点讨论如下方面：

失效的用户身份验证（Broken User Authentication）：由于API需要依赖那些被嵌入到调用中的会话令牌，令牌已对客户端进行身份验证，因此如果未能在API中实施多因素身份验证和基于凭据的登录，而仅靠基本的密码验证的话，这样的验证机制显然是不足的。攻击者可以轻松地通过冒充合法用户的身份，来迫使API错误地允许他们访问到令牌。而且，对于那些长期存在的令牌而言，还会导致攻击者能够长期驻留并损害系统。
失效的对象级授权（Broken Object Level Authorization）：在API中，对象级授权是一种代码级的控制机制，可用于验证对象的访问。而对于那些存在着对象级授权漏洞的API而言，外部用户可以将自己的资源ID，替换为其他用户的资源ID。据此，攻击者能够访问到指定的用户资源，进而未经授权地访问到敏感数据。
资源缺乏和速率受限（Lack of Resource and Rate Limiting）：当API不限制来自特定客户端的请求数量和频率时，它们可能会被迫进行每秒大量的调用。同时，API客户端也可以一次性请求访问多个资源与记录，从而使得应用服务器为了立即给多个请求提供服务，而出现过载。这种由于客户端的单次过多请求，而阻碍服务器处理正常请求的能力，便是常见的拒绝服务（DoS）攻击。此外，缺乏速率的限制还会引发攻击者，对于身份验证端点开展暴力破解式的攻击。
批量分配（Mass Assignment）：批量分配的漏洞发生在自动将用户的输入传递给对象、或程序变量的API时。虽然此项功能简化了代码的开发，但一些用户可以通过初始化和覆盖服务器端的变量，从而危及到应用程序的安全。也就是说，攻击者主要会通过在伪造请求时，猜测和提供额外的对象属性，来达到该目的。此外，他们还可以通过阅读应用程序的相关文档、或识别出允许其修改服务器端对象的弱API端点。
安全错误配置（Security Misconfigurations）：各种安全错误配置都会对API构成不同的威胁，其中包括：

（1）详细的错误消息（Verbose error messages）：一些API会发送包含着栈跟踪和描述性系统信息的错误消息，让接收者能够了解到应用程序是在后台如何工作的。

（2）错误配置的HTTP标头（Misconfigured HTTP Headers）：标头会暴露出安全漏洞，攻击者可以利用此类漏洞，去窃取数据，并执行更深层次的复杂攻击。

（3）非必要的HTTP方法和服务（Unnecessary HTTP methods and services）：如果管理员未能关闭不必要的服务，那么恶意攻击者便可以使用不同的HTTP方法，去修改已发布的内容与资源。

（4）不安全的默认配置（Insecure default configurations）：API往往会与第三方依赖项相关联。不过，在默认情况下，此类关联是不安全的，需要我们通过增强安全态势，来应对由此扩大的攻击面。

PART 03

API安全性的优秀实践

下面我将给出各项有助于缓解API攻击的优秀实践：

1、使用节流和速率限制

您可以设置一个临时状态，以评估每个API请求，并通过使用反垃圾邮件措施、以及防止滥用等措施，来抵御拒绝服务攻击。在实施限流的过程中，您可以重点考虑的因素包括：每个用户应该允许占用多少数据、以及何时应该实施限制。

此外，在某些API中，开发人员可以设置“软”速率限制，允许客户端在较短的时间内临时超出请求限制。由于可以处理同步和异步请求，因此设置超时成为了最直接的避免DoS和蛮力攻击、以及管理REST API安全性的实践之一。例如：各种编程语言都可以通过队列库目录来管理请求队列。其中，请求队列库能够支持已创建的可接受最大请求数的API，并且将其余的请求放入等待队列中。

2、扫描API漏洞

为了保持API服务的持续安全性，启用自动化扫描、漏洞识别、以及在软件生命周期的各阶段及时弥补各种漏洞是至关重要的。自动化的扫描工具通过将应用程序的配置与已知漏洞数据库进行比较，实现了安全漏洞的自动检测。

3、对REST API实施HTTPS/TLS

在实践过程中，我们需要针对每个API实现完整性、机密性和真实性。而作为一种安全协议，HTTPS和传输层安全（Transport Layer Security，TLS）可被用于在Web浏览器和服务器之间传输经过加密的数据，并在传输中保护身份验证凭据。安全团队应当考虑使用双向验证的客户端证书方式，为敏感数据和服务提供额外的保护。

此外，在构建安全的REST API时，开发人员不但应当避免因为直接将HTTP重定向到HTTPS处，而可能破坏API客户端的安全性；而且应当采取适当的措施，来转移各种跨域资源共享（Cross-Origin Resource Sharing，CORS）和JSONP请求，毕竟两者往往具有跨域调用的各种基本漏洞。

4、限制HTTP方法

REST API允许Web应用执行各种类型的HTTP（动词）操作。不过，由于HTTP上的数据是未经加密的，一旦我们使用此类HTTP操作，则可能会被某些攻击向量拦截和利用到。作为一种优秀实践，我们应该禁止本质上已被证明极其不安全的HTTP方法（如：GET、PUT、DELETE、以及POST等）。如果无法完全禁止此类使用的话，安全团队也应当采用相应的策略，以严苛的允许列表形式，来审查此类方法的使用，进而拒绝所有与列表不匹配的请求。

当然，我也推荐您使用RESTful API身份验证的各项优秀实践，来确保请求的客户端只能在操作、记录和资源集合上，使用指定的HTTP方法。

5、实施充分的输入验证

原则上，我们不应当盲目地信任API客户端提供的各种数据，毕竟身份验证服务器最终可能会执行那些来自未经授权的用户或应用服务的恶意脚本。虽然客户端的验证已经能够给出交互式的错误指示、以及可接受的用户输入建议，但是，安全团队仍然需要在服务器端实施输入验证机制，以防止有害数据的输入，并避免不同类型的XSS和SQL注入攻击。

6、使用API网关

API网关能够有效地将客户端接口与后端的API集合相分离，提供集中式的资源，以实现API服务的一致性、可用性和可扩展性。同时，网关也能够充当反向代理，协调所有API调用所需的资源，并在身份验证后，返回适当的结果。在实践中，我们可以通过API管理平台，来处理各种遥测（Telemetry）、速率限制、以及用户认证等标准化功能，以维护内部服务之间的安全性。文章来源地址https://uudwc.com/A/DNjYk