API（应用程序编程接口）可以定义为一组指令，用代码编写，允许通过 Internet 在软件之间进行通信。API 已成为整个 DevOps 流程的关键组成部分，不仅允许软件和服务器之间通过 Internet 进行无缝集成和通信，而且还改进了整个 DevOps 流程并允许相对轻松地构建更复杂的软件。使用 API 所取得的成功见证了其使用率和流行度的飙升，尤其是在过去 12 个月中。
昨天的 API 攻击与今天的 API 攻击
由于 API 越来越受欢迎，它们已成为网络攻击的重点。仅在过去 12 个月中，API 攻击流量就增长了 681%，95% 的公司根据研究报告报告了 API 安全事件。API 攻击可以描述为出于恶意目的滥用或非法使用或尝试使用 API，通常是为了非法访问服务器以泄露数据或导致服务中断。
过去，API 攻击主要依赖于针对已知漏洞，例如 SQL 注入攻击和 XSS 攻击。如今，API 攻击要复杂得多——不良行为者会戳戳刺探以了解公司 API 中的业务逻辑漏洞并瞄准这些漏洞。
昨天的 API 攻击是如何运作的？
由于 API 充当软件之间通过 Internet 进行通信的网关，因此它们通常存储有关实现方法及其结构的敏感信息。当攻击者获得此信息的访问权限时，它可用于发起网络攻击，尤其是利用已知 API 漏洞或配置不当的 API 的攻击。因此，当滥用 API 的漏洞导致未经授权的访问或数据泄漏时，API 攻击就会起作用。
已知 API 漏洞的类型以及如何防范它们
SQL 注入攻击——SQL 注入攻击使用特制的恶意 SQL 代码通过 SQL 数据库插入输入字段，以潜在地访问不打算显示的信息。代码开发不良的应用程序更容易受到 SQL 攻击。
XSS 注入攻击——与 SQL 攻击类似，跨站点脚本 (XSS) 攻击使用恶意制作的 JavaScript 代码插入输入字段，以潜在地访问数据库并非法访问信息。同样，当软件开发不当时，也会发生 XSS 攻击。
推荐
应实施输入验证。输入验证确保用户输入与预期参数匹配。这些可以防止 SQLi 和 XSS 攻击。
其他类型的 API 攻击
如今，大多数攻击的目的是通过利用 API 漏洞获得对服务器的未授权访问，随后导致服务中断或数据被盗。针对 API 的一些最常见的攻击是：
DDoS 攻击
当攻击者通过同时请求数千个连接来淹没 API 的内存时，就会发生针对 API 的分布式拒绝服务 (DDoS) 攻击。目的是通过使可用资源无法访问来淹没内存并导致服务中断。虽然 DDoS 攻击不会导致信息泄露，但它们的目的是阻挠。
建议——应监控、过滤和验证所有入站流量。还应实施速率限制。
中间人攻击 (MiTM)
当攻击者偷偷拦截、中继和/或修改两个客户端之间的请求或通信时，就会发生中间人攻击。对于 API，攻击者可以拦截会话令牌发布 API 和 HTTP 标头与用户之间的通信。这可能会授予攻击者对用户帐户的访问权限，从而可能导致数据和个人信息被盗。
建议——所有网络通信都应使用 TLS 加密。TLS 确保连接保持私密，每个连接都有一个唯一生成的加密密钥。
资产管理不当
当有不止一种方法访问应用程序数据库环境时，就会发生这种类型的 API 攻击。通常，在应用程序的生产状态期间，多个 API 端点连接到生产环境；当这些端点被遗忘且未被删除时，攻击者就有机会使用它们发出 API 请求并可能获得对敏感数据的访问权限。
建议——应正确记录生产阶段使用的所有 API，以便删除多余的 API 以防止未经授权的访问。
通信加密不佳
传输层安全 (TLS) 为 Internet 上的数据传输提供最基本的加密形式。这确保了传输的数据无法以纯文本形式读取，从而在传输敏感数据时增加了一层安全性。加密不当的流量可能导致 MiTM API 攻击。
建议——TLS 应该跨网络使用，因此网络流量是加密的，因此在 MiTM 攻击的情况下，攻击者无法读取数据。
过多的数据暴露
Web 应用程序使用 API 定期处理和传输敏感数据。因此，可能会发生数据泄露，通常是在 API 未在响应到达客户端之前对其进行过滤时。数据泄露可能导致未经授权访问信用卡信息、会话令牌、密码、私人健康信息等信息。
建议——应过滤和验证所有 API 调用和响应，以便只允许授权的请求和响应通过。
损坏的用户身份验证
API 认证是一项核心服务，用于识别和授权客户端访问应用程序。当会话和凭证管理都存在弱点时，就会发生用户身份验证失败的情况。这可能导致身份验证令牌被盗，进一步使攻击者能够使用它们来暴力破解 Web 应用程序或获得未经授权的访问。
建议——API 开发人员应确保在构建 API 时符合正确的标准，并且应避免使用 API 密钥进行用户身份验证。还应实施多因素身份验证。
损坏的对象级别授权
损坏的对象级别授权是一种不安全的直接对象引用。当未正确设置对象级权限时会发生这种情况，导致使用用户输入功能对资源进行未经授权的访问。
建议——应适当管理用户授权，特别是对于整个身份验证过程中的登录用户。
批量分配
当用户可以通过利用特制请求来包含对应用程序功能产生不利影响的参数来覆盖服务器端变量时，就会发生批量分配。当请求主体被解析为对象或利用某些框架级别的自动绑定功能（如 Spring 和 .NET）时，可能会发生批量分配。
建议——开发 API 时不应使用自动绑定功能。此外，限制可由客户端修改的属性。这可以防止将请求主体解析为对象。
参数篡改
当攻击者操纵在服务器和客户端之间交换的参数（通常存储在 cookie、隐藏的表单字段或 URL 查询字符串中）以修改或窃取应用程序数据时，就会发生参数篡改。
建议——Web 应用防火墙可以防止参数篡改。将应用程序输入的格式列入白名单并加密会话 cookie 也有助于防止参数篡改。
结论
随着 API 继续被组织和个人广泛用于软件开发和集成，有必要了解与使用 API 相关的风险。这些风险主要与与 API 相关的漏洞一致。虽然几乎不可能完全保护 API 免受所有可能的攻击形式，但了解针对 API 的众所周知且频繁的攻击不仅有助于拓宽您对它们的理解，还可以让组织在缓解这些攻击时做出正确的决定。
