强化Apache APISIX：集成OWASP的Coraza与核心规则集

开放全球应用安全项目（OWASP）是一个在线社区，提供有关物联网、系统软件和Web应用安全领域的免费可用文章、方法论、文档、工具和技术。OWASP提供免费开放资源，由非营利组织OWASP基金会领导。OWASP Top 10 – 2021是基于来自40多家合作伙伴组织的全面数据编制的最新研究成果。

– OWASP网站

OWASP定期发布Top 10漏洞报告，该报告针对Web应用中的漏洞。

本文将介绍如何通过Apache APISIX API网关修复其中一些漏洞。

OWASP Top 10 2021

2021年的报告中提及：

A01:2021-访问控制失效
A02:2021-加密失败
A03:2021-注入
A04:2021-不安全
A05:2021-安全配置错误
A06:2021-易受攻击和过时的组件
A07:2021-识别和认证失败
A08:2021-软件和数据完整性失败
A09:2021-安全日志记录和监控失败
A10:2021-服务器端请求伪造

欲了解更多详情，请查阅完整的报告。

修复漏洞需视其具体性质而定。例如，对于脆弱和过时的组件的修复，是一个流程驱动的任务，需要严格管理版本并淘汰旧版本。而有些漏洞的修复则属于技术范畴，仅需在反向代理或API网关中进行适当配置，比如服务器端请求伪造。

安全问题无人问津

安全是一个敏感话题，因为加强安全并不会为业务带来直接价值。以职业发展为导向的管理者不会关心安全问题，因为他们无法在下一次年度评估中展示通过提升安全增加了公司X%的利润。除非董事会高度重视安全，否则很可能无人关注。因此，大多数组织实施的所谓安全措施，实质上是基于“可辩解性”的勾选框式安全。若您有意正确实施安全措施，我在之前的博客文章中分享了一些想法：将安全视为风险对待。

总之，应用程序安全往往得不到足够的预算支持，甚至没有任何预算。因此，我们必须精明行事，寻找现成的组件。幸运的是，OWASP提供了一个即开即用的配置来应对前十大安全问题，该配置名为核心规则集，但遗憾的是，它主要针对ModSecurity。

ModSecurity，有时也被称为Modsec，是一个开源的网络应用防火墙（WAF）。最初设计为Apache HTTP服务器的一个模块，它已经发展成为在包括Apache HTTP服务器、Microsoft IIS和Nginx等多个不同平台上提供一系列超文本传输协议请求和响应过滤功能以及其他安全功能的工具。它是根据Apache许可证2.0发布的免费软件。

– 维基百科上的ModSecurity

虽然理论上可以通过Apache APISIX配置来配置Nginx，但还有一种更直接的方式。

OWASP Core Ruleset和Coraza

Core Ruleset的描述与我们的需求非常相关：

OWASP® ModSecurity Core Rule Set（CRS）是一组用于ModSecurity或兼容的网络应用防火墙的通用攻击检测规则。CRS旨在以最少的虚警来保护Web应用程序免受各种攻击，包括OWASP十大攻击。CRS提供了对许多常见攻击类别的保护，包括：

SQL注入（SQLi）

跨站脚本攻击（XSS）

本地文件包含（LFI）

远程文件包含（RFI）

PHP代码注入

Java代码注入

HTTPoxy

Shellshock

Unix/Windows Shell注入

会话固定

脚本/扫描器/机器人检测

元数据/错误泄露

– OWASP® ModSecurity 核心规则集网站

OWASP 还提供了 Coraza，这是 ModSecurity 的一个 Go 库版本。Coraza Proxy Wasm 基于 Coraza 构建，并实现了 proxy-wasm ABI，该 ABI 为代理指定了一组 Wasm 接口。最后，Apache APISIX 提供了 proxy-wasm 集成。

综合应用

总结如下：

OWASP 提供了一份十大 Web 安全漏洞列表。
通过核心规则集为 ModSecurity 实现这些漏洞。
Coraza 是 ModSecurity 的一个版本，作为 proxy-wasm 实现可用。

我们可以通过这种方式配置 Apache APISIX，使其具有合理且安全的默认设置。开始吧。

首先，Coraza 并未包含在 Apache APISIX 的发行版中。不过，通过 Docker 在此添加它很简单：

Dockerfile

FROM apache/apisix:3.8.0-debian

ENV VERSION 0.5.0                                                           #1
ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip                        #1

ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2

USER root                                                                   #3

RUN <<EOF

  apt-get install zip -y                                                    #4
  unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm
  rm $CORAZA_FILENAME
  apt-get remove zip -y
  chown -R apisix:apisix /usr/local/apisix/proxywasm

EOF

USER apisix                                                                 #5

定义变量以提高可维护性
获取 Coraza Wasm 发布版。
在最近的 APISIX 版本中，用户为 apisix 以增强安全性。由于我们需要安装软件包，因此必须切换到 root。
安装 unzip，因为它尚未安装，解压下载的存档，移除存档，卸载 unzip，并更改提取文件夹的所有者。
切换回用户 apisix。

接下来，我们需要配置 APISIX 本身以使用 Coraza Wasm 插件。

YAML

wasm:
  plugins:
    - name: coraza-filter                                                   #1
      priority: 7999                                                        #2
      file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm              #3

在 Wasm 代码中设置过滤器的名称
将其设置为最高优先级，以便在任何其他插件之前运行。
指向提取的文件路径（参见上面的 Dockerfile）

最后，我们可以将插件分配给路由或将其设置为全局规则，以应用于每个路由。我使用静态配置：

YAML

global_rules:
  - id: 1
    plugins:
      coraza-filter:                                                        #1
        conf:
          directives_map:                                                   #2
            default:
              - SecDebugLogLevel 9                                          #3
              - SecRuleEngine On                                            #4
              - Include @crs-setup-conf                                     #5
              - Include @owasp_crs/*.conf                                   #6
          default_directives: default                                       #7

配置 coraza-filter 插件，现在它已可用。
定义配置。这里，我们定义了一个名为 default 的配置，但我们可以定义多个并在不同的路由中使用不同的配置。
增加日志级别以查看日志中的情况。
开启引擎。
使用 Coraza 设置。
使用所有规则。我们可以选择我们想要的规则以获得更精细的控制。
使用上面定义的 default 配置。

我们继续定义路由来测试我们的设置。让我们称这个路由为 /get：

Shell

curl localhost:9080?user=foobar

响应如预期：

JSON

{
  "args": {
    "user": "foobar"
  }, 
  "headers": {
    "Accept": "*/*", 
    "Host": "localhost", 
    "User-Agent": "curl/8.4.0", 
    "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", 
    "X-Forwarded-Host": "localhost"
  }, 
  "origin": "192.168.65.1, 176.153.7.175", 
  "url": "http://localhost/get?user=foobar"
}

现在，让我们尝试在查询字符串中发送 JavaScript。这种请求在服务器端是不可能预期的，因此我们的基础设施应该保护我们免受其害。

Shell

curl 'localhost:9080?user=<script>alert(1)</script>'

响应是一个 403 HTTP 状态码。如果我们查看日志，我们可以看到以下提示：

Plain Text

Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"]
Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection
Coraza: Warning. Javascript method detected
Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1

Coraza 完成了任务！

结论

大多数组织并未对安全进行激励。因此，我们需要精明行事，尽可能利用现有组件。

通过结合使用Coraza和核心规则集，我们可以加强Apache APISIX以抵御OWASP Top 10威胁。

深入探讨

APISIX – 与Coraza集成

本文完整源代码可在GitHub上找到。

Source:
https://dzone.com/articles/hardening-apache-apisix-with-the-owasps-coraza-and