API安全测试：主动识别API漏洞

2021-08-09 16:33:38 【大中小】

20多年的开发部署后，API已经到处都是。2021年的调查研究中，73%的企业表示自己已经发布了超过50个API，且这一数字还在不断增长。

API在当今几乎每个行业里都起着举足轻重的作用，而且随着它们逐渐迈向业务战略前沿，其重要性还在平稳上升。出现这种现象其实毫不意外：API无缝连接不同应用和设备，带来前所未有的业务协同效应和效率。

但是，与软件任何其他组件一样，API也免不了存在漏洞。基于此，如果没有经过间隔的安全测试，API也有可能引入全新的攻击途径，将用户暴露在前所未有的风险之下。坐等生产部门发现API漏洞是不现实的，你只会等来严重延迟。

API可不仅仅是简单连接企业各种应用，它们还会以无法预测的方式改变功能。API可能引入的很多独特缺陷都广为黑客所知，他们开发出不同方法攻击API，从而访问底层数据和功能。

开放Web应用安全项目(OWASP)的API Top 10表明，通过身份验证的合法用户利用API漏洞的情况并不鲜见，此类用户利用看似合法的调用，实际上却意图篡改API。这种攻击旨在篡改业务逻辑并利用设计缺陷，对攻击者极具吸引力。

每个API都是独特且专有的。因此，其软件漏洞也是独特且“未知”的。防御者很难发现这类可导致业务逻辑或业务过程级攻击的漏洞。

左移安全已广为多数企业接受，整个开发过程贯穿持续测试的做法已成常规。然而，API安全测试常被漏掉，或者执行时缺乏对所涉风险的重复理解。为什么会这样?原因不止一个：

因此，尽管左移安全已普遍受到大多数企业重视，但API安全测试却常被排除在DevSecOps蓝图之外。

这是个令人遗憾的状况，因为相比传统应用漏洞，API漏洞需要更长的响应时间：近期一项调查中，63%的受访者报告称需要更长时间来修复API漏洞。考虑到应用对API的依赖和快速采用情况，这一数字可能还会继续上升。

虽然大多数安全主管都意识到了API安全测试的重要性，但仍有近一半的安全主管称自己尚未将API安全测试解决方案完全集成进开发流水线中。

要实现全面的安全方法，第一步就是仔细考察当前对于应用安全测试的普遍态度：静态安全测试和动态安全测试。

静态安全测试采用白盒测试方法，基于应用的已知功能创建测试，审查应用的设计、架构或代码，包括数据在流经应用时可采取的诸多复杂路径。

动态安全测试采用黑盒测试方法，基于应用摄入特定输入集的的预期性能创建测试，不考虑内部处理或底层代码知识。

至于API，开发人员和安全团队常常争论这两种方法哪种最适用，各自的支持理由包括：

虽然有点扫兴，但以上两种观点都不完全正确。事实上，两种方法都需要确保广泛覆盖和处理一系列可能的场景。尤其是随着近期API攻击的兴起，防御者不能在可扩展性、深度和频率方面冒险。

这种情况下，“灰盒”API安全测试成为了一个有趣的替代方案。因为没有用户界面，知道应用的内部运行机制(如参数、返回类型等)有助于高效创建针对业务逻辑的功能性测试。

理想状态下，综合考虑API安全测试的各个方面可以更好地创建灰盒解决方案，弥补单个方法的不足。此类业务逻辑方法可智能检查其他测试类型的结果，并自动或手动调整应用改进的测试。

业界越来越意识到API安全防护应贯穿整个API生命周期，将API置于安全控制的前端和中心。

为此，我们必须找到简化和弥合企业API安全测试的方法，将API安全测试标准融入开发周期并加以实施。这样一来，在运行时监测的帮助下，安全团队就能够在一个地方获得对所有已知漏洞的可见性。并且，左移API安全测试还可以削减成本并加速修复。

此外，如果能够自动化测试工作流，企业就内置了对重测试的支持：测试、修复、重测、部署的循环，保持流水线平稳运行，避免出现瓶颈。

采用业务逻辑方法执行API安全测试可以提高全生命周期API安全计划的成熟度，改善企业安全状态。

然而，这种现代方法需要能自学习的工具，通过摄入运行时数据逐渐改进性能，从而深入了解应用的结构和逻辑。

这将涉及创建能够随运行过程不断学习的自适应测试引擎，积累关于API行为的深入认知，以便智能逆向工程其隐藏的内部工作机制。借助运行时数据和业务逻辑信息，企业能够享受黑盒和白盒两种方法带来的好处，实现可见性增强和自动化控制。

除了逐渐普及，API也给Web应用带来了更多漏洞。许多企业甚至不清楚自身API应用范围和漏洞情况。黑客可以很容易地通过可用API探测已知和未知漏洞。

然而，企业常常忽视了API安全测试，像对待Web应用一样处理API安全测试。大多数测试方法，比如黑盒测试和白盒测试，并不适合API测试。

自然语言处理和人工智能(AI)的结合提供了可行“灰盒”选项，能够自动化、扩展和简化API安全测试的复杂过程。

行业动态