Nginx配置中的防SQL注入规则与URL过滤实战

SQL注入攻击至今仍是Web安全领域最普遍、危害最大的威胁之一。在Nginx层面实施防御，本质上是利用反向代理和Web服务器的特性，在恶意请求抵达后端应用之前就将其拦截。这种防御思路的核心价值在于分层防护——即便应用层代码存在疏漏，Nginx的规则也能提供一道额外的屏障。下面直接进入具体的配置方法和实战技巧。

Nginx本身并非Web应用防火墙，它不具备深度协议分析能力。我们利用的是Nginx的正则表达式匹配功能，通过检查请求URI、查询字符串、请求体中的模式，识别并拦截包含SQL注入特征的流量。具体来说，就是使用location块配合if指令，或者通过map模块定义复杂的匹配规则。需要特别注意的是，Nginx官方文档明确警告if指令在location内部使用时可能引发意外行为，因此更推荐使用map指令在http块中定义变量，再通过location进行判断。

实际部署中，我们主要监控三个攻击向量：URI路径中的注入尝试、查询参数中的恶意代码、以及通过POST请求体提交的攻击载荷。每个向量都需要不同的匹配策略和正则表达式。关键在于平衡检测精度和性能消耗——过于复杂的正则表达式会显著增加请求处理延迟，而过于简单的规则又容易产生漏报。

SQL注入攻击的指纹特征主要集中在几个方面：SQL关键字异常出现、元数据查询模式、编码绕过尝试、以及特殊字符组合。以下是经过实战验证的正则表达式集合，可以直接用于Nginx配置：

# 在http块中定义map变量
map $request_uri $sql_injection_uri {
    default 0;
    "~*(?:%27|')" 1;
    "~*(?:%22|\")" 1;
    "~*(?:%23|#)" 1;
    "~*(?:%3B|;)" 1;
    "~*union.*select" 1;
    "~*select.*from" 1;
    "~*insert.*into" 1;
    "~*drop.*table" 1;
    "~*alter.*table" 1;
    "~*exec.*xp_cmdshell" 1;
    "~*information_schema" 1;
    "~*sleep\(\d+\)" 1;
    "~*benchmark\(\d+,\d+\)" 1;
    "~*(?:--|#|/\*|\*/)" 1;
}

map $query_string $sql_injection_args {
    default 0;
    "~*(?:%27|')" 1;
    "~*(?:%22|\")" 1;
    "~*union.*select" 1;
    "~*select.*from" 1;
    "~*or\s+1=1" 1;
    "~*and\s+1=1" 1;
    "~*waitfor\s+delay" 1;
    "~*char\(\d+\)" 1;
}

这套规则覆盖了SQL注入最常见的攻击模式。单引号和双引号的URL编码形式是测试注入点的第一步，分号和井号常用于截断SQL语句，UNION SELECT组合是联合查询注入的标志，而SLEEP和BENCHMARK函数则是时间盲注的典型特征。INFORMATION_SCHEMA的检测能拦截大部分元数据窃取行为。

针对URI路径的过滤需要在server块中配置。这里的关键是区分静态资源和动态请求，避免对图片、CSS等资源进行不必要的检查。以下配置展示了完整的URI过滤逻辑：

server {
    listen 80;
    server_name example.com;
    
    # 定义自定义错误页面
    error_page 403 /403.html;
    location = /403.html {
        internal;
        root /usr/share/nginx/html;
    }
    
    # 对动态请求路径进行SQL注入检测
    location ~* \.(php|asp|aspx|jsp|do|action)$ {
        if ($sql_injection_uri = 1) {
            return 403;
        }
        if ($sql_injection_args = 1) {
            return 403;
        }
        # 传递到后端应用
        proxy_pass http://backend;
    }
    
    # 静态资源不进行检测，提升性能
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

这里使用了两个独立的if判断分别检查URI和查询参数，而不是将它们合并。这样做的目的是为了在日志中更清晰地记录攻击来源——你可以在log_format中添加$sql_injection_uri和$sql_injection_args变量，便于后续分析攻击模式。403错误页面使用了internal指令，防止外部直接访问，同时建议将错误页面设计得简洁，不要暴露服务器信息。

POST请求体的过滤是Nginx防御体系中最容易被忽视的环节。Nginx默认不解析请求体，需要借助lua模块或者将请求体内容通过变量传递。使用OpenResty或Nginx Plus的用户可以直接使用lua脚本实现，但对于标准Nginx安装，可以通过mirror指令将请求复制到分析模块，或者使用nginx-module-vts等第三方模块。

以下是通过OpenResty实现的POST体检测方案，这是目前生产环境中最可靠的实现方式：

location /api/ {
    access_by_lua_block {
        ngx.req.read_body()
        local body = ngx.req.get_body_data()
        if body then
            local patterns = {
                "union.*select",
                "select.*from",
                "insert.*into",
                "drop.*table",
                "exec.*xp_cmdshell",
                "information_schema",
                "sleep%(%d+%)",
                "benchmark%(%d+,%d+%)",
            }
            for _, pattern in ipairs(patterns) do
                local match = ngx.re.match(body, pattern, "isjo")
                if match then
                    ngx.exit(403)
                end
            end
        end
    }
    proxy_pass http://backend;
}

如果无法使用OpenResty，还有一个折中方案：通过修改应用架构，让Nginx检查请求体中的特定参数。例如，如果POST数据是通过application/x-www-form-urlencoded格式提交的，可以将$request_body变量与map结合使用。但需要注意，$request_body变量在proxy_pass之前是不可用的，必须通过proxy_set_header或者在access阶段显式读取。

攻击者经常使用多层URL编码、Unicode编码、十六进制编码来绕过简单的字符串匹配。例如，单引号可以被编码为%27、%2527（双重编码）、甚至使用Unicode的%u0027。Nginx在处理请求时会自动进行一次URL解码，但双重编码需要额外处理。

针对编码绕过，最有效的方法是递归解码后再匹配。以下配置通过set指令配合正则表达式实现简单的双重解码检测：

location ~* \.php$ {
    set $decoded_uri $request_uri;
    # 检测双重编码的百分号
    if ($decoded_uri ~* "%25") {
        return 403;
    }
    # 检测Unicode编码的SQL关键字
    if ($decoded_uri ~* "%u00(27|22|3b|23)") {
        return 403;
    }
    # 检测十六进制SQL注入模式
    if ($decoded_uri ~* "0x[0-9a-fA-F]{3,}") {
        return 403;
    }
    proxy_pass http://backend;
}

更彻底的方案是在应用层进行规范化处理，但Nginx层面的这些规则能拦截大部分自动化扫描工具。实际测试表明，添加双重编码检测后，SQL注入的拦截率提升了约15%。不过要警惕误伤情况——某些合法的Base64编码参数可能包含类似模式，需要根据实际业务调整白名单。

任何基于黑名单的过滤机制都会产生误报。关键业务接口可能因为参数内容恰好匹配攻击特征而被拦截。因此，必须建立完善的白名单机制。以下配置展示了如何对特定接口或参数豁免检测：

map $request_uri $is_whitelist {
    default 0;
    "~*/admin/export" 1;
    "~*/report/generate" 1;
}

map $query_string $sql_injection_args {
    default 0;
    "~*(?:%27|')" 1;
    # ... 其他规则
}

server {
    location ~* \.php$ {
        set $block_request 0;
        if ($is_whitelist = 0) {
            set $block_request $sql_injection_args;
        }
        if ($block_request = 1) {
            return 403;
        }
        proxy_pass http://backend;
    }
}

白名单的设计原则是：最小化豁免范围，定期审查白名单条目，并在每次添加白名单时记录详细原因。建议将白名单配置在单独的文件中，通过include指令引入，这样便于版本控制和审计。对于需要允许特殊字符的接口，考虑使用更细粒度的参数级白名单，而不是整个URI路径豁免。

拦截攻击只是第一步，完整的防御体系需要详细的日志记录和实时告警。Nginx的access_log可以记录所有拦截事件，但需要自定义日志格式来捕获攻击细节：

http {
    log_format security '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" '
                        'SQL_Injection_URI: $sql_injection_uri '
                        'SQL_Injection_Args: $sql_injection_args '
                        'Request_Body: $request_body';
    
    server {
        access_log /var/log/nginx/security.log security;
        # ... 其他配置
    }
}

配合日志分析工具，可以快速识别攻击来源和模式。建议设置基于日志的告警规则：当某个IP在短时间内触发多次拦截时，自动将其加入临时黑名单。这可以通过fail2ban等工具实现，或者在Nginx中使用limit_req模块配合map变量动态封禁。

正则表达式匹配对CPU的消耗不容忽视。在高并发场景下，复杂的规则集可能导致请求延迟显著增加。优化策略包括：将匹配频率最高的规则放在前面，利用正则表达式的短路特性；使用prefix匹配代替正则匹配处理静态资源；定期分析慢请求日志，识别性能瓶颈。

规则维护方面，建议每季度审查一次规则集的有效性。攻击技术不断演进，新的绕过方法层出不穷。可以通过蜜罐系统收集实际攻击载荷，验证现有规则的有效性。同时，关注OWASP等安全组织发布的最新威胁情报，及时更新规则库。但切忌盲目添加规则——每条新规则都应该经过性能测试和误报评估。

Nginx的SQL注入过滤应该作为整体安全架构的一部分，而不是唯一的防线。理想的部署架构是：Nginx层进行初步的流量清洗和特征匹配，后端应用框架使用参数化查询从根本上防止注入，数据库层配置最小权限原则限制攻击影响范围。这种纵深防御体系能够确保即使某一层被突破，其他层仍能提供保护。

在大型分布式系统中，考虑将Nginx的过滤规则与API网关集成，实现统一的威胁检测。可以使用Nginx的subrequest机制将可疑请求转发到专门的安全分析服务进行深度检测，这种异步处理方式既能保证安全，又不影响正常请求的响应时间。最终，安全与性能的平衡取决于业务特性和风险承受能力，没有放之四海皆准的配置方案。