当然可以！在Web服务器层面部署全局过滤器是拦截SQL注入请求的有效手段之一，它能在请求到达应用程序之前就把恶意流量挡在外头，减轻后端应用的安全压力。下面我会结合主流服务器给出具体实现思路和注意事项：

主流Web服务器的实现方式 #

Nginx #

Nginx可以通过内置规则配合自定义正则，或者借助第三方模块（比如ngx_http_modsecurity_module，也就是大家常用的ModSecurity）来实现。

先给个简单的自定义规则示例，直接在Nginx配置文件中添加：

server {
    # 其他基础配置...
    
    # 拦截URL中包含SQL注入特征的请求
    if ($request_uri ~* "(union|select|insert|update|delete|drop|alter|exec)" ) {
        return 403;
    }
    
    # 针对POST请求的请求体进行检查
    if ($request_body ~* "(union|select|insert|update|delete|drop|alter|exec)" ) {
        return 403;
    }
}

不过这种简单正则很容易误杀正常请求，更推荐用ModSecurity搭配OWASP核心规则集（CRS），它有成熟的SQL注入检测逻辑，能大幅降低误判率。

Apache #

Apache同样可以通过ModSecurity模块实现，搭配OWASP CRS效果更好。先启用ModSecurity模块，再在配置文件中加载规则：

<IfModule mod_security2.c>
    SecRuleEngine On
    Include /usr/share/modsecurity-crs/owasp-crs.load
</IfModule>

如果需要自定义简单规则，也可以这么写：

SecRule REQUEST_URI "@rx (union|select|insert|update|delete|drop|alter|exec)" "id:1000,phase:1,deny,status:403,msg:'SQL Injection Attempt'"

关键注意事项 #

• 误拦截风险：简单正则很容易把正常请求当成恶意请求（比如用户输入的内容里刚好包含"select"这个词），所以一定要做好测试，优先选用成熟的规则集。
• 绕过手段：攻击者可能用大小写混合（比如UnIoN）、编码（URL编码、Unicode编码）来绕过简单规则，ModSecurity这类工具会自动处理大部分编码问题，比自定义正则靠谱得多。
• 不能替代应用层防护：服务器层面的过滤是第一道防线，但绝不能完全依赖它。应用程序本身还是要做好输入验证、使用预编译语句（比如ORM的参数绑定），这才是最核心的防护手段。
• 性能影响：复杂规则会增加服务器的处理负载，建议只对动态请求（比如.php、.asp、/api/*这类路径）应用规则，静态资源直接放行，平衡安全与性能。

内容的提问来源于stack exchange，提问作者Basil Kosovan