开发人员应了解应用程序受到攻击的三个迹象

应用程序正遭受攻击。 袭击发生的频率令人担忧——根据马里兰大学的研究，每 39 秒就会发生一次——而且成功概率高得令人不安。

开发人员越来越肩负着保护这些应用程序安全的重担，他们非常清楚这一威胁。 NodeSource 和 Sqreen 在 2017 年末对 node.js 开发人员进行的一项调查发现，“超过三分之一的受访者（34%）认为他们的组织很有可能在未来六个月内成为大规模攻击的目标。” 根据我们自己的研究结果，86% 的攻击的初始攻击媒介是应用本身或身份，这种信念是合理的。

那么，发现“35％的受访者不确定如何在攻击发生时识别攻击”可能会令人不安。 他们期待着它，但他们不确定当它发生时如何识别它。 如果您不确定如何识别正在进行的攻击，那么阻止它就会非常困难。

这使得 23% 的 Node.js 开发人员 (23%) 不使用任何形式的实时防御攻击措施变得更加令人不安。

好消息是，根据我们自己对应用交付状况的研究大多数组织都采用某种形式的实时保护措施来抵御攻击。 五分之四的企业使用两种或两种以上的技术，包括Web应用防火墙（57%）、运行时应用自我保护（11%）和用户行为分析（26%）。

所有这些技术都有一个共同的特点，那就是开发人员通常所缺乏的：可视性。 可见性是必要的，因为为了检测（并希望识别）攻击，您必须能够识别异常行为。

应用及其服务具有相当可预测的使用模式。 例如，单点登录 (SSO)应用往往在周一早上使用量较大，而在周五下午使用量较小。 金融应用往往在金融事件（发薪日、纳税期结束和财政年度结束）之前被大量使用。

即使面向消费者的应用也具有可预测的使用模式，可用于帮助检测异常（且具有潜在危险）的行为。 例如，2017 年 4 月， Malauzai Software 发布了一份月度“小数据”报告，该报告基于从“435 家银行和信用合作社”收集的使用数据，涵盖了 730,000 名活跃互联网和手机银行用户的 1,320 万次登录。 在其中，我们了解到“100% 的最终用户都会看到他们的余额并查看最近的交易历史记录。 这是因为余额和最近的历史记录显示在登陆页面上，供所有人查看。 这就是他们来的原因。 77% 的时间。 77% 的时间里，用户所做的只是检查余额和历史记录。 数字银行整体互动中只有 23% 超越了余额和历史记录而执行其他任务。”

因此，你可以推断，对其他类型交易的突然兴趣可能预示着一次攻击。

不幸的是，对于每个应用来说，这样的统计数据并不总是可用的。 这就是为什么可见性（监控）很重要，这样您就可以建立一个基线，使异常变得明显。 当然，并不是所有的异常都预示着有袭击发生。 周中 SSO 服务使用量的激增可能是因为公司密码更改期限到了，或者因为周一和周二是假期，办公室里没有人。 尽管如此，拥有基线可以帮助您识别可以告诉您攻击正在进行的行为。

一定要检查这三种异常使用模式，以防它们实际上是一种攻击。 因为通常情况下，他们都是这样的。

1. 连接数急剧增加。 也许你的名气刚刚开始流行，但很有可能还有其他事情发生。 当您看到连接率明显上升时，最好立即检查网络流量是否相应增加。 如果没有，你的蜘蛛感应应该会有所警觉，因为那是一次潜在的攻击。 GET 洪水攻击是所有基于 HTTP 的 DDoS 攻击中最容易发生的，因为它们仅依赖于向应用发送大量 HTTP GET，而不做任何其他事情。 他们通常甚至不会尝试访问真实的 URL，因为其目的仅仅是消耗尽可能多的连接并迫使您陷入过载的情况。

如果这种增加专门针对提供登录的 URL 或服务，您可能会成为获取访问权限的暴力破解攻击的受害者。 

寻找服务器错误、不断下降的性能以及资源耗尽作为正在进行的攻击的迹象。

2. 出站响应的大小。 突然大量的传出响应可能表明一次成功的渗透攻击，攻击者获得了他们不应该拥有的数据。 这是成功的 SQLi 攻击的主要危险信号之一，因为攻击者经常使用通配符来获取未授权访问。 您可能认为 SQLi 是一种很好理解的攻击媒介，到现在为止我们已经涵盖了它。 但在许多行业报告中，SQLi 每年都是最成功的攻击之一。

从根本上来说，此次攻击的目的是规避数据访问的限制。 因此，攻击可能收到的不只是一条记录（甚至只有几条），而是数千条记录。 一次成功的攻击将会引人注目，因为返回的数据量将远远大于正常水平。

响应大小的任何显著差异都应该足以保证立即进行调查。

3. 崩溃并失败。 虽然这些可以通过缺陷或意外的“错误”输入来解释，但它们也可能表明试图溢出第三方库或 Web 服务器平台（或您的应用）中的缓冲区，以期利用新的（或旧的）漏洞。 虽然如今系统能够自行“重启”是件好事，但忽视它们需要重启的原因就不是一件好事了。

尽管你可能想忽略偶尔发生的崩溃，但不要这么做。

不要忽视崩溃和故障，并考虑允许您隔离故障系统的架构，直到您可以检查它们。

显然，这不是一个详尽的列表，但它是一个很好的开始，可以帮助我们识别应用应用何时可能受到攻击 - 并阻止它。

注意安全！