这篇文章并不是一个评估或适当的测试，它只是一个实验，看看这是如何运作的。

ModSecurity CRS + OWASP JuiceShop

ModSecurity是一个开源的web应用程序防火墙，可以在恶意请求攻击实际应用程序服务器之前过滤掉它们。OWASP Mod安全核心规则集(CRS)定义了一组用于ModSecurity的预定义规则。CRS本身提供了一组配置选项，可用于调整其行为。最基本的选择是偏执狂级别。通过增加偏执程度，会激活越来越多的攻击规则，从而增加用于确定请求是否为攻击的规则数量。不幸的是，更多的规则也意味着更多的错误空间，这将导致有效的请求被错误地检测为攻击。这些病例通常被称为假阳性结果。

在这篇文章中，我将只使用偏执狂级别1，这意味着在不干扰正常请求的情况下阻止一系列广泛的攻击。我将在以后的博客文章中探讨如何提高偏执的程度。

ModSecurity可以通过几种方式集成到应用程序中，在本例中，我将使用反向代理模式，使用提供的ModSecurity docker映像设置该模式非常容易

设置

Docker为JuiceShop和ModSecurity编写设置

这个设置中一个不幸的细节是，ModSecurity容器只支持ip地址作为代理的上游地址。这使得设置更加复杂，因为我们不能只使用juiceshop域名。作为备份，我将转发内部的JuiceShop端口，并使用我的本地ip和JuiceShop端口作为代理的上游地址。在非测试设置中，我们应该确保没有人能够连接到端口3001，因为这会让攻击者绕过WAF。

测试设置

为了测试这个设置的有效性，我们将使用JuiceShop的一些出色功能，即端到端(e2e)测试套件和“挑战跟踪”功能，即跟踪哪些挑战已经解决。哪些漏洞被成功利用。这将方便地查看哪些攻击被阻止了，哪些通过了。

为了进行比较，我运行了两次测试，启用和不启用ModSecurity CRS。运行测试套件之后，我下载了挑战列表，并查看了哪些挑战在ModSecurity设置中没有得到解决，但在未受保护的设置中得到了解决。列表:

在ModSecurity设置中无法解决的挑战/漏洞

为了进行比较，这里有一个关于ModSecurity所阻碍的挑战类别的概述:

假阳性率

看着被阻止的挑战列表，ModSecurity能够阻止的攻击数量让我非常兴奋。但第二次看的时候，我很困惑。在不了解应用程序的情况下，系统无法阻止许多攻击。为了理解这里发生了什么，让我们看一下伪造优惠券的例子。对于这个挑战，您需要伪造优惠券，以获得订单的80%折扣。

Web应用程序防火墙如何知道哪些优惠券是有效的，哪些不是。如果他们不能阅读编码的优惠券，他们怎么知道哪些折扣是可以接受的呢?

让我们来试试当你提交一个有效的优惠券时会发生什么:

尝试提交有效的优惠券，对ModSecurity保护的JuiceShop

有一个简单的解释，防火墙一直在阻止任何优惠券请求，而不仅仅是恶意的。这当然是一个问题，因为它阻碍了正常的应用程序使用。对于每一个错误(误报)，我们都必须为应用的规则定义一个异常。

因此，为了完成设置，我们仍然需要定义为out应用程序定制的异常，以确保它对我们的普通客户仍然可用。

结论

在这种设置中，阻塞漏洞的比率非常低。大多数被阻止的攻击都被阻止了，因为整个功能都没有功能。但这仍然是一个非常基本的设置运行在最小的偏执狂水平。为了进行正确的设置，我们必须通过定义现有规则的异常来教授有关应用程序的ModSecurity细节。

由于误报率很高，很难说哪些请求被正确阻止了，哪些只是过于激进规则的附带损害。

在下一篇文章中，我将尝试定义这些规则，以将假阳性率降到最低，然后我们将尝试提高偏执的程度。这将比这个简单的设置更好地概述ModSecurity的功能。

原文：https://medium.com/@j12934/testing-out-modsecurity-crs-with-owasp-juiceshop-649830932365

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】