下列不属于常见SQL注入漏洞防护手段是下列

把用户输入直接拼进SQL语句，然后指望WAF挡一切——这思路本身就歪了。不属我见过一个真实案例：某电商后台的于常订单查询接口，开发者在代码里写了WHERE id = '" + request.getParameter("id") + "'，注入但同时又加了一个正则过滤器，漏洞只拦截单引号和--。防护结果攻击者用1 OR 1=1没引号照样跑通，手段整张订单表被拖走。下列那个正则，不属就是于常典型的“看起来像防护，其实不是注入”。

常见SQL注入防护手段，漏洞翻来覆去就那几样：参数化查询（预编译）、防护存储过程（内部也走参数化）、手段白名单输入验证、下列最小权限数据库账户、转义特殊字符（注意，是配合参数化用，不是替代）。这些手段的共同逻辑是——把数据和指令彻底分开，让用户输入永远无法改变SQL语句的结构。

那什么不属于常见防护手段？我列几个经常被误认的。

第一，WAF（Web应用防火墙）。WAF能挡一部分已知攻击模式，但它不是“防护手段”的核心层。WAF的规则库有滞后性，攻击者用注释变形、编码绕过、分块传输，很容易打穿。把WAF当主要防线，等于把保险柜钥匙挂在门口保安身上。它算辅助缓解措施，不算常见防护手段里的“正牌军”。

第二，前端JavaScript校验。这个更离谱。前端校验只防君子不防小人，攻击者抓包直接改请求，或者用curl发原始HTTP，前端那点正则连影子都摸不着。我见过一个项目，前端把'转成'，后端却直接urldecode后拼SQL，一打一个准。前端校验是用户体验优化，不是安全边界。

第三，隐藏表单字段或URL参数。有人觉得把id藏在hidden input里就安全了。浏览器开发者工具一开，或者Burp Suite一抓，什么hidden都现形。隐藏字段只防普通用户误操作，不防攻击者。

第四，错误信息屏蔽。把数据库报错关掉，确实能增加盲注难度，但它本身不阻止注入发生。攻击者可以用时间盲注、布尔盲注，照样把数据抽出来。错误屏蔽是信息泄露防护，不是注入防护。

第五，定期备份数据库。备份是灾难恢复手段，不是防护手段。数据被注走了，备份能恢复，但泄露已经发生。把备份当防护，逻辑上就错位了。

还有一个更隐蔽的误区：用addslashes()或类似转义函数就以为万事大吉。转义函数在特定字符集下（比如GBK）会被宽字节注入绕过。%df%27一进去，转义反斜杠被吃掉，单引号照样逃逸。转义必须配合正确的字符集设置和参数化查询，单独用就是纸糊的墙。

那真正的防护长什么样？我拿一个Python Flask + SQLite的例子说。错误做法：cursor.execute("SELECT * FROM users WHERE name = '%s'" % name)。正确做法：cursor.execute("SELECT * FROM users WHERE name = ?", (name,))。就这一个问号，把数据变成参数，SQL结构在编译阶段就固定了。攻击者输入' OR '1'='1，数据库只会把它当做一个普通字符串去匹配，不会当成逻辑条件。

再说最小权限。给Web应用连数据库的账户，只给SELECT、INSERT、UPDATE、DELETE，别给DROP、FILE、xp_cmdshell。这样即使注入成功，攻击者也删不了表、读不了文件、执行不了系统命令。我见过一个生产库，Web账户居然是sa，权限全开。注入点一爆，直接xp_cmdshell提权，服务器都沦陷了。

所以回到题目：下列不属于常见SQL注入漏洞防护手段是——如果选项里有“部署WAF”、“前端输入过滤”、“隐藏表单字段”、“关闭数据库错误回显”、“定期备份”，这些都不是核心防护手段。核心就一条：参数化查询，让数据和指令分家。其他都是补丁，补丁可以打，但不能当承重墙。

写代码的时候，别偷懒。拼字符串一时爽，数据泄露火葬场。我见过太多项目，功能跑通就上线，安全测试全靠运气。SQL注入二十年了，还是OWASP Top 10常客，不是因为它难防，是因为太多人觉得“我这个小系统没人盯”。攻击者可不挑系统大小，自动化扫描器一天能扫几十万个IP。你省的那几分钟，可能就是后面几个月的应急响应。