Web 应用程序安全中的漏洞
拼凑式安全如何导致泄露
A 公司和 B 公司的故事
这是 A 公司和 B 公司的故事，它们采用了貌似不同的 Web 应用程序和 API 安全方法，但都有一个微妙但关键的缺陷。这个缺陷导致两家公司都发生了数据泄露事件（以及所有相关的负面后果）。
A 公司拥有最安全的 API 保护措施。该公司阻止所有模式违规，对过度请求进行速率限制，并使用最新的威胁情报来将已知的恶意 IP 地址列入阻止列表。如果 A 公司用 mutual TLS 替代基于密码的 API 身份验证，安全性可能会更高，但他们从未发生过安全事故。
但是，他们的 API 安全、威胁情报源和 Web 应用程序防火墙(WAF)均来自不同的供应商。而由于供应商更新，为其 API 安全提供信息的威胁情报已不再兼容保护其帐户登录页面的 WAF。因此，攻击者能够在该页面上使用一个新的 SQL 注入漏洞，并获取一个合法用户的用户名和密码。随后，攻击者向其 API 发送通过身份验证和模式验证的请求，并获取了大量敏感数据。
与此同时，B 公司的 Web 应用程序拥有防范 DDoS 攻击的全面保护。B 公司还向想要与其应用程序集成的付费用户暴露了一个 API。
攻击者在暗网上购买了一个合法付费用户的 API 密钥。利用这个密钥，攻击者对 B 公司的 API 服务器发起了一次低频、慢速的 DDoS 攻击。攻击者激活一个机器人，由它以不规律的间隔发送请求。机器人发送的每个 API 请求都被 API 服务器视为合法请求，因为它带有一个可接受的 API 密钥。不幸的是，B 公司的后端团队忘记了通过他们的 DDoS 缓解服务提供商代理他们的 API 服务器，尽管他们的所有其他服务器都受到了保护。
随着请求数量不断增加，API 服务器不堪重负，最终完全无法为 B 公司的其他用户提供服务。很多用户沮丧不已并取消了付费账户。
A 公司和 B 公司的共同问题是什么呢？
拼凑式的解决方案导致疏忽和漏洞
以上示例中，两家公司的 Web 应用程序和 API 安全方法都是由多家供应商的解决方案拼凑而成的。这些解决方案没有被集成，也容易出现人为错误。
要理解为什么这会成为问题，请考虑 Web 应用程序和 API 安全框架的典型组成部分：
WAF： 阻止针对 Web 应用程序和 Web 资产的攻击
机器人管理： 负责质询或阻止可能的恶意机器人
DDoS 缓解： 面对任何类型的 DDoS 攻击(无论是大规模攻击，还是低频慢速攻击)，都能使 Web 资产保持在线
API 保护： 包括针对 API 的速率限制、模式验证、身份验证等
A 公司和 B 公司都采取了以上所有保护。但是，由于他们的 Web 应用程序安全解决方案是拼凑而成的（尽管是最佳的解决方案），其中存在可被攻击者加以利用的漏洞。
对 A 公司来说，其 WAF 和 API 保护是叠加而非集成的，每一个都必须面对并阻止攻击。即使其中一个解决方案阻止了攻击，另一个仍有可能被绕过。B 公司的 DDoS 防护措施没有保护他们的 API 基础设施，他们的机器人管理没有检测到来自机器人的 API 请求，而且他们的身份验证也很薄弱，容易被攻击者破解。
以上只是一些潜在漏洞的例子。Web 应用程序安全的其他常见漏洞包括：
有限的威胁情报： 威胁情报过时、没有到达正确的位置或格式不兼容。A 公司就发生了这种情况。
来自太多来源的过多威胁情报：导致误报、冗余和其他低效问题。
机器人误报： 这可能会让用户感到沮丧，减慢服务速度，并导致执行不力。
警报疲劳： 平均而言，每家企业使用 45 种网络安全工具，来自多家供应商，都会产生警报。太多分散的产品可能会导致人员忽略威胁，以便完成他们的工作。
不充分的身份验证： A 公司和 B 公司都容易遭受某种形式的凭据盗窃。
不可扩展的威胁情报： 在大规模攻击或多手段攻击下，硬件安全设备会成为瓶颈，无法处理大量流量。
随着网络攻击的复杂性提高和技术水平提高，这些漏洞正在变得越来越危险。麦肯锡(McKinsey)表示， 如今的攻击者“包括高度复杂的组织，会利用集成工具，以及应用人工智能和机器学习的能力。”现代的攻击者往往比他们的目标行动更快，改进战术的速度也更快。
API 的额外风险
对现代组织的 Web 应用程序基础设施而言，API 越来越重要。今天，Cloudflare 处理的所有动态流量中，58% 基于 API，而且这个比例仍在增长。事实上，很多组织将自身描述为 API 优先。此外，Cloudflare 拦截的恶意 API 流量比例超过了 Web 流量，表明 API 已经成为攻击者的主要目标。
鉴于 API 往往深度嵌入到 Web 应用程序中，其安全性必须放在第一位。然而，出于好心的内部团队通常会快速部署 API，而且往往在未咨询安全团队的情况下进行。结果：许多 Web 应用程序的安全漏洞可以追溯到糟糕的 API 安全性。
例如，当一个支持实时包裹追踪的 API 被发现缺乏基本授权时，美国邮政服务(USPS)就遭到了一次与 API 相关的入侵。通过使用显示数据集中的所有记录的通配符搜索参数，已登录用户可以查询任何其他用户的帐户信息。 这导致 6000 万美国邮政服务帐户持有人的数据面临风险。
整合解决方案
如果 A 公司和 B 公司不是使用拼凑而成的安全产品，而是将他们所有的 Web 应用程序和 API 安全服务整合到一个统一的平台上，那些不同的服务都互相集成，而且有关公司基础设施状态的数据都显示在单一位置，以便他们能够快速评估攻击及安全态势，情况会如何呢？
由于使用了单一平台，A 公司能够确保其所有 Web 应用和 API 安全框架组件都能获得最新的威胁情报，并在攻击开始之前就予以阻止。B 公司将能够轻松将其 DDoS 防护扩展到所有服务器。
使用单一平台意味着更容易管理，更少漏洞。
这种整合式的 Web 应用程序安全方法需要高度可扩展的基础设施，能够代理所有类型的流量。过去几十年来，组织通常会在需要防御新的攻击或需要扩展规模时购买设备。但是，基于云的服务更容易扩展，并应该能够代理任何类型的基础设施。虽然整合式平台不能保证防御所有攻击，但它肯定会有助于以上两家假想的公司。
不仅仅是思想实验： WAAP 的重要性日益增长
这不仅仅是一个假设性的思想实验。Gartner 将这些整合服务定义为“Web 应用程序和 API 保护 ”，简称 WAAP。2022 年，Gartner 预测“到 2024 年，在生产环境中实施多云策略的组织中，70% 将倾向于使用云 Web 应用程序和 API 保护平台 (WAAP) 服务，而不是 WAAP 设备和 IaaS 原生 WAAP。”
WAAP 不仅仅是另一个缩写：整合 WAF、机器人管理、DDoS 保护、API 安全和其他服务对现代组织来说越来越重要。由于互联网的全球性，Web 应用程序和 API 持续不断地面临来自多个地点、不同规模和复杂程度的攻击。2022 年，IBM 报告指出，83% 被调查的公司经历了一次数据泄露，全球平均泄露成本达到 435 万美元，美国平均泄露成本平均达到 944 万美元。这并不令人意外。
另一个考虑因素：异构基础设施
如果 A 公司和 B 公司今天开始从头构建他们的应用程序和API，他们可能会将它们全部托管在云端，也许只使用一个托管提供商以便于部署。但实际上，大多数组织都部署了混合式基础设施，包括传统的本地数据库服务器、基于云的第三方 API 以及托管在多个云中的应用程序服务。这些部署方式具有许多优点，但也具有自己的安全挑战。
例如，某个云服务提供商提供的原生安全性可能无法扩展到其整个基础设施。首先，为了保护基础设施，需要发现和映射所有的基础设施，这也可能并非易事。最后，他们的安全产品可能不兼容组织技术堆栈中的其他解决方案。
因此，除了整合关键的 Web 应用程序安全功能之外，WAAP 还需要与基础设施无关，也就是说，它必须能够适用于任何类型的基础设施或云部 署。
整合式、基础设施无关的 Web 安全性
Cloudflare 是云原生并与基础设施无关的，已经提供 Web 应用程序安全服务超过十年，并将所有这些能力作为一个整合式平台提供，在单一界面中管理。Cloudflare 还有一个优势，就是观察到大部分互联网流量，每秒处理超过 4600 万次 HTTP 请求，平均每天阻止 112 0 次网络威胁。因此，Cloudflare 更容易发现零日威胁和新攻击。
Cloudflare 就影响当今技术决策者的最新趋势和主题发布了系列文章，本文为其一。
深入探讨这个话题
Cloudflare 被 Gartner® Web 应用和 API 保护（WAAP） 魔力象限报告评为“领导者”。
Get the report!
关键要点
阅读本文后，您将能够了解：
拼凑式安全解决方案如何造成安全漏洞
这些漏洞可能如何表现的示例
为什么 Gartner 建议使用一个与基础设施无关的 Web 应用程序安全平台进行整合