从生产到代码，主动识别API漏洞！

哈客cc lv.2

发布时间：2022-03-02 05:43:26 714

API对攻击者具有吸引力，而不仅仅是企业

请记住，API不仅仅是连接应用程序；它们以不可预测的方式改变功能。API可能带来的许多独特弱点为黑客所熟知，他们开发了不同的方法来攻击您的API，以便访问底层数据和功能。

根据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还为web应用程序带来了更大的漏洞。许多组织甚至不知道他们的API和漏洞的程度。黑客可以通过可用的API轻松地探测已知和未知的弱点。

然而，API安全测试经常被忽视，处理方式与web应用程序相同。大多数测试方法，例如黑盒和白盒测试，都不利于API测试。

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

特别声明：以上内容（图片及文字）均为互联网收集或者用户上传发布，本站仅提供信息存储服务！如有侵权或有涉及法律问题请联系我们。