DoSECU 安全报道 10月19日消息：我知道上个月我在专栏中针对SQL注入式攻击的严重性发出警告后，并没有人立即将SQL注入式攻击漏洞从他们的网络应用软件中清除。我也知道多数人们，即使他们已经意识到软件漏洞的重要性，但是仍然认为不会产生太大影响，而且很容易解决。或者他们认为他们的网络入侵检测系统能应对这些问题。
所以本月我再次回来旧话重提。
入侵防御系统在防范使用诸如SQL注入式攻击手段的攻击者来说，大部分情况下是无效的。
正如我上个月在专栏中所说的，攻击者喜欢把攻击的目标对准SQL服务，因为这里是多数员工使用应用软件的所在。现在想像一下高价值的目标与大部分情况下无法侦测攻击的安全工具共存会是什么状况。这如何成为可能呢？回想一下我对可怕的"or 1=1"攻击的描述。
告诉我们的入侵检测系统留意"or 1=1"字符串是很简单的事。但是别被此蒙骗，因为"2=2"和"3=3"也同有效。那么"foo=foo"和
"xyzzy=xyzzy."也是同样原理。这样发展下去会是怎样的呢？
不错，使用静态签名定义–但由于你必须写下签名字符串的无限长数字来识别每次攻击，因此像目前许多常用入侵检测系统产品使用的方法每次都是失效的。那些"n=n"攻击是SQL注入式攻击中最琐碎的。
问题之一是所有以网络为基础的入侵检测工具都缺乏上下文来有效的判断HTTP请求是否包含恶意输入。
接下来在入侵检测系统领域还有一个隐藏的黑暗面。你知道我们安全人员是如何告诉软件使用者使用SSL加密来保证敏感数据在网络上传递时的安全的吗？确实，对网络流量进行加密（这是个好办法）就相当于给监控用的摄像头加上有效的镜头盖。入侵检测系统产品无法看到SSL加密数据包内部的内容。
通过对我们的敏感数据进行SSL加密，我们可以收回观测带有恶意有效负荷迹象数据的入侵检测系统传感器。即使他们可以胜任侦测SQL注入式攻击的职责，但SSL加密会导致他们的工作无法完成。
因此这就意味着我们要停止使用入侵检测系统和SSL马？当然不是。这只是说明我们必须清醒的意识到我们所用技术的局限性。
在很多时候入侵检测系统能十分有效的进行侦测。已知病毒，蠕虫，木马等的爆发会经常兴风作浪来冲击使用入侵检测系统进行监控的网络。
入侵检测系统工具甚至能侦测到许多新型的攻击。举例来说，僵尸网络和其他木马经常会在被感染计算机上安装网络服务。当攻击者和这些服务进行联系时，桌面系统计算机从网络层面上来说就更像是一台服务器。多数现有的入侵检测工具在之前已知的木马病毒发作时会注意到这些网络活动。
但是不要因此而麻痹，以为入侵检测系统产品在侦测所有的网络应用软件攻击上都是有效的。采取实际应用软件安全措施的唯一地方就是应用软件本身的内部。这种安全是无法购买得来的。
同样，我们也不能放弃SSL。SSL依然是目前可用的最普遍也最广为认可的网络加密技术。实际上我们必须采用SSL加密技术来保护传输过程中的敏感数据。
这就意味着我们的入侵检测产品注定无法刺穿SSL的屏障吗？在很多甚至是多数情况下，确实如此。目前在企业级体系架构中，我们可以将SSL流程卸载到前端处理器，将入侵检测系统放置在这些处理器的后面。但这是很多小型企业所力不能及的。
我们也在考虑托管在应用软件服务器上的入侵检测系统，但是需要警告和重申的是许多入侵检测系统产品在侦测应用软件层攻击上是比较薄弱的。在应用软件内部，还没有替代应用软件层防御的办法，包括入侵检测在内亦是如此。
我们也不能忽略另一个使用SSL的巨大优势–那就是验证。在多数应用软件中，只有服务器对客户的验证，或者附加值服务的验证。在除了服务器证书外还使用客户端证书的领域，SSL加密能我们提供非常强大的相互验证。
尽管如此，没有一项技术是完美的。我们也不会对此大惊小怪对吗？目前现有的入侵检测技术是有用的工具，但是我们不能事事依靠这项技术。应用软件攻击是他们的弱点之一。让我们接受这个事实，将注意力转移到研发更加安全的应用软件上去吧。
