API正在推动世界各地公司正在进行的数字化转型计划。董事会对改进数字体验的需求如此之大，以至于供应商在过去几年中在其平台上的API流量激增。谷歌的API平台服务Apigee最近指出，API流量增加了46%，达到2.2万亿次调用。
不幸的是，API消耗的增加反映了对API基础设施的攻击的增长。例如，包括LinkedIn，佩洛顿和Facebook等在内的知名品牌因其API受到攻击而遭受数据泄露。这一趋势将继续下去。Gartner估计，到明年，API滥用将从不频繁的攻击媒介转变为最常见的攻击媒介，从而导致企业Web应用程序的数据泄露风险增加。
为什么会出现 API 安全问题
三个关键模式解释了为什么 API 安全问题如此频繁：
应用程序开发正在发生变化：自从应用程序以整体方式使用自行开发的库构建以来，已经有一段时间了。在这些情况下，服务器端层控制逻辑，保护所有数据，并确定哪些数据可以公开，哪些数据不能公开给客户端。使用基于 API 的体系结构，应用程序由编排数百个内部和外部服务组成。控制逻辑主要发生在客户端，如果直接调用 API，则完全绕过该逻辑。
开发团队比以往任何时候都更加敏捷：开发人员可以使用跨多种语言的丰富开发框架、强大的 IDE 以及许多开源和商业工具来提高工作效率。我们从每六个月发布一次应用程序到每天发布几次。另一方面，应用程序安全团队依旧主要依赖于手动流程来测试 API。
安全性被认为为时已晚：开发团队首先专注于交付功能。在大多数公司中，安全性不是主要目标;相反，它是开发过程中的一个强制性（通常是可怕的）瓶颈。检查安全漏洞有时被认为是乏味的，分析工具会引发数百个误报供开发人员梳理。
这三个问题形成了一个爆炸性的组合：以疯狂的速度交付的API增加，再加上由AppSec团队驱动的手动流程，这些团队的数量远远超过开发人员。
保护数据，而不是边界
每当企业公开API时，他们实际上是在企业边界上“打一个洞”来公开数据。
这意味着应用程序安全的重点必须从保护组织的外围环境转移到保护存储和访问数据的位置。传统的应用程序安全解决方案（例如通常部署在边缘的 Web 应用程序防火墙 （WAF））不再是保护现代架构的最佳选择。
阻止 API 攻击：一切都与上下文有关
工具需要上下文信息来决定阻止 API 流量。例如，对 API 的几种典型攻击涉及使用不正确的谓词（即调用 GET /token 而不是 POST /tokens）或操纵数据本身（例如，通过大量分配或泄漏数据来注入数据）。对于 WAF，这些调用只是有效的 HTTP 调用。WAF 没有上下文来决定 POST 是好的，但 GET 不是，或者 /令牌有效，而 /admin/令牌无效。
上下文可以是静态的，也可以是动态的（例如，基于流量构建），但在任何情况下，工具都需要上下文来做出适当的决策。上下文定义有效的单个调用、所需的安全设置、授权规则、有效的调用工作流以及流经 API 的数据。上下文信息同样可以在测试或执行时使用。
如果没有上下文，工具需要诉诸于负面的安全模型，并且由于它们没有关于流量的信息，因此您唯一的解决方案是通过规则和模式描述您认为不可接受的内容。随着新漏洞的出现，需要编写新的规则。
在设计时构建上下文
幸运的是，使用 API，我们可以用事实上的标准（如开放API或异步API）来描述API合约。更好的是，我们可以在设计时编写任何代码之前执行此操作。
API 协定成为测试 API 安全性所需的上下文的关键部分，但对于在运行时保护 API 也至关重要。它实现了积极的安全模型方法，这长期以来一直是安全领域的目标。如果您知道流量必须是什么，则可以拒绝访问除预期流量之外的所有内容，并且无需手动构建规则来捕获不良流量或利用机器学习等技术来猜测流量应该是什么。
机器可读的 API 描述还支持 API 生命周期每一步的自动化，包括合同的自动化分析、自动化功能测试、自动化数据验证和改进的自动化安全测试。这意味着应用程序安全团队可以专注于复杂的渗透测试方案，并将其扩展到开发团队的敏捷性级别。
准备保护，准备获胜
我们已经看到安全从业者如何尝试利用传统上部署的现有技术来保护应用程序，并使其适应以保护API。不幸的是，它们基于负面安全模型，并且每个新的API都代表了进入公司系统的潜在唯一攻击路径，因此这些解决方案无法扩展以应对挑战。
新一代 API 安全解决方案已经出现，旨在解决保护 API 的积极和消极安全模型方法。作为决策过程的一部分，安全官员需要决定他们的最终目标是什么。它是将安全性嵌入到从设计到生产的API生命周期之一吗？还是在运行时实施补丁以解决已知问题？还是两者兼而有之？可以肯定的是，随着 API 攻击面的不断增加，安全从业者需要仔细考虑其 API 安全需求，并确保所选的解决方案与他们计划在当前和未来采用的安全态势策略保持一致。
为什么API滥用是下一个大型安全战场
- 实施 API 发现，以创建所有已批准和未经批准的 API 的完整且准确的清单。
- 消除未经批准的 API。
- 识别和修复软件和实施漏洞，这些漏洞使受制裁的 API 容易受到攻击。
这些都是必要的实践，并且有一些优秀的资源，如OWASP Top 10，为查找和消除API漏洞提供了高级路线图。
但这就是问题所在。发现 API 和解决 API 漏洞只是了解和缓解 API 风险的冰山一角。
为什么？
因为即使您在对API进行编目和消除漏洞方面做得很完美，它们依旧可能非常容易受到滥用。API 滥用对业务的影响可能与漏洞利用一样具有破坏性。
API滥用是一种非常不同的问题
正式API安全的早期努力从以下角度看待这个问题：
- API 编码或配置方式中的漏洞
- 利用这些漏洞的攻击
API滥用的不同之处在于攻击者没有利用任何类型的技术漏洞。相反，他们使用 API 的方式不是创建它们的组织所希望的。
这听起来简单而良性，但API滥用的影响可能是毁灭性的。毕竟，许多组织通过 API 公开其核心业务逻辑和数据。威胁参与者窃取此知识产权所需的唯一事情是具有正确凭据的正确API。
API 滥用对业务的影响可能是毁灭性的
一个极端的例子说明了API滥用的级联影响是剑桥分析公司（CA）丑闻，该丑闻在2018年将Facebook推向了聚光灯下。在这种情况下，CA滥用Facebook的开放API来收集有关至少8700万用户的大量数据。这是通过Facebook测验完成的，该测验利用了一个非常宽松的设置，该设置允许第三方应用程序连接信息以及用户及其社交关系。
从这些数据中获得的人口和心理特征随后被出售并用于影响公众对2016年美国总统大选和英国“英国退欧”公投等问题的舆论。
所有这些都不涉及利用FacebookAPI基础设施中的基础设施漏洞。相反，CA只是以创建时没有打算或预期的方式使用了Facebook的公共API。简而言之，Facebook暴露了一个最终被滥用的核心业务API。
每个公开 API 的组织每天都在较小的规模上做同样的事情。应假定每个 API 都有与之关联的潜在滥用案例方案。
例如，考虑一下我们许多人现在每天使用的网上银行，预算和财务规划应用程序和服务。API 是使这些类型的便利设施发挥作用的关键。但是，拥有凭据的威胁参与者可以很容易地利用通过这些API访问的固有业务逻辑和数据，使这些知识产权与金融机构的商业利益和账户持有人的个人利益相悖。
更复杂的是，API滥用很难被发现。由于威胁参与者使用有效凭据并以类似于合法用法的方式与 API 交互，因此许多第一代 API 安全产品无法检测到它们。
如何抵御日益严重的 API 滥用威胁
首先，不要把目光从 API 漏洞上移开。构建包含发现、漏洞评估和修复的 API 安全基础与以往一样重要。
但是，扩展 API 安全状况以解决包括 API 滥用在内的一系列完整 API 威胁需要三个重要的转变。
扩展您对 API 攻击构成的思考。在 API 安全性之外，我们主要通过两种方式查看威胁：
- 用于发现、记录解决漏洞的系统方法（例如，MITRE CVE）
- 已知攻击技术（例如，米特雷阿特&CK）的活知识库
我们从第一个开始，从OWASP API前10名开始。但是，不幸的是，在了解API滥用方面，我们错过了第二个。
在为此制定行业框架之前，您的团队必须更广泛地考虑 API 攻击的本质。
- 分析有关 API 和活动的更多数据。大多数第一代 API 安全方法仅监视单个 API 调用，或者充其量监视短期会话。这样做的问题是，除了看起来像合法活动之外，API滥用可能会在几分钟，几小时或几天内展开。
采用基于 SaaS 的方法确实是捕获和分析足够大的数据集的唯一方法，以真正了解上下文中的 API 使用情况，并发现正常基线行为中的“低速和慢速”API 滥用和异常。
- 利用 API 来发现滥用实例。API活动的速度和数量太大，人类无法主动监控和理解。同时，许多传统的API安全技术无法理解他们所观察到的业务影响。
这是机器学习和AI技术的出色应用。假设您遵循上述建议并转向SaaS，除了有更多的数据要分析之外，您还可以访问计算能力来执行大数据分析。
我们将永远无法预测未来，也无法完全预测威胁行为者滥用API的下一种新颖方式。但我们可以使用人工智能来设定正常行为的基线，了解所涉及的业务实体，并发现表明可能滥用的异常情况。
参考：securityboulevard |
