当谈到涉及应用程序和数据泄露的违规行为时,人们几乎总是将矛头指向开发人员。 很多时候,这是正确的方向。 注入攻击和基于堆栈的漏洞几乎总是不安全代码的结果。 通常是因为违反了零安全规则。
但我们不能把所有违规行为都归咎于开发商。 事实是,即使开发人员可以编写出完全安全的代码,您仍然需要应用服务来防御许多其他攻击。
这是因为应用安全性是一个堆栈。 有一些攻击利用了协议和网络原理,而这些协议和原理是无法通过简单的“安全编码”消除的。 进一步复杂化安全性的是,这些攻击通常无法被应用检测到,因为它们缺乏区分恶意请求和合法请求的可见性。
具体来说,有三种攻击是开发人员根本不应该负责处理的。 相反,这些攻击最好由上游部署的应用服务来检测和缓解,因为可以通过可视性和上下文来帮助阻止这些攻击。
我们使用术语“容量耗尽”来描述传统的分布式拒绝服务攻击,以区分基于网络过载的攻击和“沿堆栈向上”攻击应用层的攻击。 它们是不同类型的攻击,因此我们需要能够防御它们,但我们这样做的方式却采取截然不同的解决方案。
容量耗尽攻击只是一次闪电战。 大量流量针对某项特定服务,目的是压倒处理请求的任何设备/基础设施/软件。 其原理是,所有设备(无论是硬件还是软件、本地还是云端)的资源都是有限的。 因此,通过发送足够多的请求,设备可能会不堪重负,并关闭对其后面的所有内容的访问。
开发人员无法有效防止这种攻击的原因是应用依赖平台和主机操作系统来管理网络。 容量耗尽型 DDoS 攻击的目标是网络堆栈,能够消耗大量共享资源,以致应用几乎无法处理请求,从而无法确定自己是否受到了攻击。
安全编码无法阻止这种情况——这不是由于漏洞而导致的攻击。 这实际上并不是系统任何部分的代码的错误。 事实很简单,无论我们多么努力地假装没有硬件,但硬件就是资源的来源,而资源是有限的。
容量激增的 DDoS 攻击最好通过位于应用上游的高容量、高性能应用服务来检测和缓解。 距离攻击源越近越好。
没有漏洞,就没有安全编码解决方案。
沿着堆栈向上移动到应用层,我们发现一种称为第 7 层(或 HTTP)DDoS 的阴险拒绝服务形式。 这些攻击令人愤怒,因为它们是漏洞利用,但不是由于漏洞或不安全的编码造成的。 这些攻击之所以能够成功,是因为 HTTP 及其实现系统的性质。
第 7 层 DDoS 攻击通常有两种类型:慢速和快速。 缓慢的第 7 层 DDoS 通过假装网络连接不佳并缓慢地吸走合法请求的响应来消耗资源。 这会消耗资源,因为 Web 应用程序是基于连接的,而维持这些连接的资源再次是有限的。 通过连接足够多的客户端并发出合法请求以缓慢地接收响应,攻击者能够占用应用资源。 这使得合法客户端几乎不可能连接,从而有效地进行拒绝服务攻击。
这种攻击特别邪恶且难以检测——除非您将网络速度与接收速度进行比较。 也就是说,上游的应用服务可以看到客户端的网络特性,并可以更准确地确定这些客户端是故意接收速度慢还是真的存在网络问题。 确定合法性对于阻止此类攻击至关重要。
基本上,这些攻击利用协议层(HTTP)进行攻击,安全编码对此无能为力。
没有漏洞就没有安全编码解决方案。
最后但同样重要的是撞库攻击。 过去几年中,通过入侵事件暴露的凭证数量令人难以置信,因此这次攻击需要重点防范。
撞库攻击攻击通常依赖于机器人或工具,因为它们基于利用大量现有用户名/密码转储的暴力破解原理。 你很少会发现手动进行的撞库攻击攻击。 成功的撞库攻击攻击不是不安全编码的结果*。 攻击者并没有试图利用任何东西,只是试图利用不良的密码习惯和无法识别正在进行的攻击。
为了检测这些攻击,您需要能够确定客户端不是合法的人类。 因此,在某种逆向图灵测试中,您需要提出挑战并以这些自动化系统无法回答的方式使用 CAPTCHA。
无论多少安全编码都无法阻止这次攻击成功。 改进密码习惯和检测攻击尝试是避免屈服于这一日益严重的互联网祸害的最佳方法。
没有可利用的代码,没有安全的编码解决方案。
* 不安全的编码可能会引发撞库攻击攻击。 毕竟,大量违规行为都是由于基于代码的漏洞而发生的,这些漏洞导致了大量可用于此类攻击的凭证列表。
认识到何时可以使用安全编码来防止攻击以及何时不能使用安全编码非常重要。 这很重要,因为我们不能总是将每次成功的攻击都归咎于开发人员。 安全需要系统级的思考;我们需要多种解决方案,因为我们需要防御多种类型的攻击。
为了有效和成功地防御大多数组织在不久的将来将遭受的各种攻击,区分非常重要。 不要浪费时间试图强迫开发人员防御攻击,因为它 (1) 不是由于不安全的编码而导致的漏洞,或 (2) 由于缺乏可见性而无法实现。
我们需要从服务系统战略性地处理安全性问题,无论来源或攻击面是什么,该系统都在正确的位置提供正确的安全性。
注意安全。