如何用Nginx配合Burp Suite完成网站安全测试？

Nginx在安全测试中既可以作为被测目标的前置反向代理，也可以充当流量调度节点，而Burp Suite负责拦截、修改和重放HTTP请求。两者配合时最常见的困难不是工具本身，而是代理链路中的证书校验和请求标记问题。以下内容会从环境搭建、证书处理、请求追踪以及Nginx自身配置缺陷四个维度展开。

测试环境里的Nginx角色与代理链路

在正式测试前，必须先明确Nginx在网络拓扑中的位置。如果Nginx直接暴露公网并作为入口，Burp Suite通常配置在浏览器与Nginx之间，形成浏览器到Burp再到Nginx的链路。此时Burp Suite需要解密浏览器发出的HTTPS流量，同时还要与Nginx建立新的HTTPS连接。若Nginx只作为内部反向代理，Burp Suite也可以直接指向Nginx监听的端口，省去中间链路。

以常见的本地测试场景为例，Nginx监听443端口并转发到后端应用，后端可能是Tomcat、Node.js或Python服务。Burp Suite的代理监听地址通常设置为127.0.0.1:8080，浏览器代理指向该地址。当浏览器访问https://ipipp.com时，Burp Suite先接收请求，再根据上游代理设置或目标主机重新发起连接。这里需要特别注意的是，如果Nginx开启了强制HTTPS跳转或HSTS，Burp Suite必须正确处理好两段连接，否则会出现证书不匹配或无限重定向。

对于需要测试Nginx本身配置的情况，建议在隔离环境中用Docker快速拉起一套Nginx与后端应用，这样可以通过修改配置和查看日志来观察Burp Suite发送的请求是否按预期到达。下面是一段基础的Nginx反向代理配置，用来模拟真实目标。

server {
    listen 443 ssl;
    server_name ipipp.com;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    location / {
        proxy_pass http://backend:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

证书信任：让Burp Suite解密Nginx的HTTPS流量

Burp Suite作为中间人代理，会使用自己的CA证书签发伪造的目标站点证书。浏览器必须信任Burp的CA证书，否则报错。这一步通常在Burp Suite的Proxy标签页中导出CA证书，再导入到浏览器或操作系统的信任库。但对于Nginx端，如果Burp Suite与Nginx之间也是HTTPS，那么Burp Suite需要验证Nginx的证书。默认情况下，Burp Suite会校验目标主机的证书链，若Nginx使用的是自签名证书，Burp Suite会拒绝连接。

解决这个问题有两种方式。第一种是在Burp Suite的Project options中关闭对目标主机的证书校验，但这会让测试过程脱离真实场景，因为攻击者同样不需要信任证书。第二种更稳妥的做法是为测试环境生成一套内部CA签发的证书，Nginx使用该证书，同时把该CA导入Burp Suite的信任库，这样既保持了加密链路，又不会影响证书校验逻辑。使用OpenSSL生成证书的命令如下。

# 生成内部CA私钥和证书
openssl req -x509 -newkey rsa:2048 -days 365 -nodes -keyout ca.key -out ca.crt -subj "/CN=TestCA"
# 生成Nginx服务器私钥和CSR
openssl req -newkey rsa:2048 -nodes -keyout server.key -out server.csr -subj "/CN=ipipp.com"
# 使用内部CA签发服务器证书
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365

把ca.crt导入Burp Suite后，Burp Suite与Nginx之间的HTTPS握手就能正常完成。浏览器端仍然需要导入Burp的CA证书，因为浏览器信任的是Burp签发的伪证书，而Burp信任的是内部CA签发的Nginx证书。这条信任链理顺之后，Burp Suite就可以解密完整的请求和响应内容，不会出现乱码或握手失败。

利用Nginx配置标记测试流量并排查误报

安全测试中经常出现一个问题：日志里的请求无法区分是正常业务流量还是Burp Suite发出的扫描流量。尤其是当测试环境与开发环境共用部分服务时，扫描请求可能污染统计数据，或者触发告警后难以溯源。此时可以在Nginx侧增加自定义请求头标记，让Burp Suite在发起请求时自动携带。

Burp Suite的Intruder和Scanner模块支持自定义请求头。例如在每次扫描请求中加入X-Burp-Test: true，然后在Nginx的日志格式中记录该请求头。修改nginx.conf增加日志字段：

log_format security '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_burp_test"';
access_log /var/log/nginx/security.log security;

这样所有Burp Suite发出的请求都会在access_log中留下true标记。测试结束后，只需要过滤该字段就能快速统计扫描范围。同时，如果后端应用因为扫描而崩溃，也能从日志中定位到具体的请求内容，减少排查时间。需要注意的是，生产环境不建议长期开启这类自定义头记录，因为会增加日志体积，而且攻击者也可能伪造相同请求头绕过一些简单的日志过滤规则。

除了请求头标记，还可以利用Nginx的map指令或条件判断将来自Burp Suite的流量单独路由到测试后端。例如在Nginx中判断$http_x_burp_test是否存在，如果存在则转发到backend_test，不存在则转发到backend_prod。这样可以在不影响真实用户的情况下对测试流量进行隔离，适合灰度环境下的安全扫描。

针对Nginx自身安全配置的测试要点

Nginx本身也可能成为攻击入口，常见的问题包括Host头注入、请求走私、TLS版本过低、目录穿越等。Burp Suite可以直接对Nginx入口发起测试，但要注意大流量扫描可能触发限速或封禁。建议先用Burp Suite的Repeater功能手动构造几个关键请求，再逐步扩大扫描范围。

例如测试Host头注入时，可以将请求中的Host字段修改为恶意域名，观察Nginx是否将其传递给后端应用。如果后端应用使用$_SERVER['HTTP_HOST']生成密码重置链接或跳转地址，就可能被利用。Burp Suite的Repeater中发送如下请求：

GET /reset-password HTTP/1.1
Host: evil.com
Connection: close

如果响应中包含指向evil.com的链接，说明Host头被后端信任。Nginx本身可以通过server_name限制允许的主机名，也可以在后端应用中强制使用固定域名，避免依赖客户端提供的Host值。

另一个测试方向是Nginx的路径规范化问题。Nginx在location匹配时对URI的处理与后端应用可能存在差异，Burp Suite可以发送包含..、编码斜杠或空字节的请求，观察是否能够绕过访问控制。比如请求/admin/../user，如果Nginx将/admin的ACL规则应用到该请求，但后端实际解析为/user，就可能产生越权。这类测试需要结合后端框架的具体行为，Burp Suite的Intruder模块可以批量生成多种编码变体。

最后要检查Nginx是否暴露了不必要的模块或状态页面。例如stub_status模块如果配置不当，可能通过/nginx_status泄露连接数、请求数等信息。Burp Suite扫描目录时如果发现该路径，应进一步确认是否允许未授权访问。对于生产环境，建议将状态页面绑定到内部地址，并增加基础认证。

NginxBurp Suite安全测试修改时间：2026-10-04 00:31:23