application中无法阻止的攻击

您的应用可以（并且应该）阻止各种基于 HTTP 的攻击。 OWASP Top 10 是可从任何应用内检测和预防的攻击技术的典型示例。 包括静态和动态分析以及渗透测试在内的大量工具可以确保这些漏洞不会进入生产环境。 当然，前提是，这种安全测试被转移到 CI/CD 流程中，而不是作为拨动开关（或位）让用户可以访问它的最后一步。 

即使你已经消除了开发中发现的所有潜在漏洞，应用仍然存在风险。 这是因为有些攻击无法（我说的无法）被应用检测到。 事实上，当攻击到达应用时，已经太晚了。

我当然说的是应用层（HTTP）DDoS攻击。 您知道，吸血鬼利用 HTTP 协议本身来吸收应用最后一滴可用的计算和内存，以使其对合法用户变得毫无用处。

HTTP DDOS 攻击基本上有两种类型：快速攻击和慢速攻击；洪水攻击和漏水攻击。

洪水袭击

基于泛洪的 HTTP DDoS 攻击利用了应用程序需要接受 HTTP 请求并对其做出响应这一事实。 这就是他们的噱头，不是吗？ 他们确实这么做了。 无论请求到来的速度有多快，他们都会这样做。 即使请求的速度会在几分钟或几秒钟内耗尽该服务器可用的资源，它也会尝试响应。 请注意，每个应用程序（实际上是每个设备、服务、系统等……）在任何时候都可以保持打开的 TCP 连接数量都有一个上限，超过上限后它就不能再打开了。 当达到上限时，任何后续请求都会被忽略。 当浏览器或应用程序等待系统指定的时间过去后，用户会遇到无害的“正在尝试连接...”状态，然后因无法连接而道歉。

这种攻击来得非常快（因此称之为“山洪暴发”），其速度超出了系统扩展以满足需求的能力。 在这种情况下，即使是自动扩展也无济于事，因为配置和启动应用程序新实例所需的时间大于攻击剥夺现有实例的所有资源所需的时间。

排水攻击

相反的攻击——消耗攻击——可以完成同样的任务，但是会强制应用程序保持连接打开的时间比必要的时间长。 它通过假装拨号上网来实现这一点；每秒从应用程序中流出几滴数据，而不是它实际能够接收数据的速率。 这样做意味着连接持续时间更长，如果你对足够多的连接这样做，你基本上会陷入与洪水攻击相同的境地：资源枯竭。

这两种攻击都无法从应用内部检测到。 他们为什么会这样？ 对于应用来说，这些请求都是合法的；它们都是格式良好的、基于 HTTP 的数据请求，应用程序可能每天会应答数千次。 HTTP 标头或有效负载中没有任何标志表明请求的恶意性质。 应用完全无法察觉这些请求背后的恶意，因为它无法看到网络或更广泛的环境——特别是维护所有打开连接的主列表的服务器会话表。 我将省去技术细节和关于多线程环境中的线程、进程和数据波动性的讲解，只是坚持“无法看到其他请求的处理”。

可以说，应用本身无法确定任何给定的请求是否属于更大规模攻击（洪水）的一部分，或者其行为是否与其已知功能（耗尽）不一致。

救援的代理

对两者都具有可见性的是位于应用上游（前面）的代理。 这是因为代理可能正在进行负载均衡，因此必须注意当前正在处理多少个请求以及有多少个请求进入，因为它必须将它们发送到集群（或池，如果您愿意）中的一个应用程序。

它还必须知道将响应发送到哪里，因此它知道客户端及其网络连接（通常只将客户端 IP 地址发送到应用程序，仅此而已）。 与应用不同的是，它具有检测洪水攻击和耗尽攻击所需的可视性，并在它们吞噬应用程序资源之前阻止它们。

这就是为什么基于代理的服务（例如 WAF（Web应用防火墙）或甚至高级负载均衡器）在当今的应用安全策略中发挥着关键作用的原因。 因为他们具有可见性和手段来检测预示着攻击的异常行为 - 并像大蒜和吸血鬼一样将其驱除。

而且由于这些传统的“网络”服务必然会成为应用架构的一部分，因此，DevOps 方法倾向于扩展其范围并更包容那些自然倾向于应用的服务，如应用程序安全性和可扩展性（负载均衡），这似乎是合乎逻辑的。

应用s无法阻止每一次攻击，特别是那些需要一定程度的可见性的攻击，而应用程序却无法做到这一点。 然而，与 Web 应用程序安全和负载均衡等应用程序亲和服务协同工作，可以提供检测和击退更全面的攻击的方法，以确保更少的中断和漏洞。