sql盲注更难发现是因为不回显错误或数据，攻击者依赖响应时间、布尔真假或dns外带判断逻辑，服务端日志仅显示正常200请求，易被忽略；常出现在搜索框、分页参数、排序字段等“只读”接口。

SQL盲注为什么比普通注入更难发现

因为盲注不回显错误或数据，攻击者靠响应时间、布尔真假或DNS外带判断逻辑，服务端日志里只看到一堆正常200请求，容易被当成误操作忽略。它常出现在搜索框、分页参数、排序字段等看似“只读”的接口里。

典型现象包括：同一页面不同参数值返回时间差异明显（如id=1 AND SLEEP(5)比id=1慢5秒）；或修改order by 1→order by 2时页面突然空白但无报错。

• 必须禁用information_schema表的SELECT权限给业务账号，否则攻击者能直接查库名、表名、列名
• 关闭SHOW PROCESSLIST权限，防止通过该命令窥探当前执行语句结构
• 避免在错误日志中记录完整SQL——哪怕只是调试模式，也要过滤掉WHERE后的内容
• 对所有涉及ORDER BY、GROUP BY、LIMIT的动态字段，改用白名单映射而非字符串拼接，例如：$sort_map = ['created_at' => 'created_at DESC', 'price' => 'price ASC']

越权提权攻击常从哪个权限配置漏洞切入

不是密码弱，而是MySQL权限系统存在“匹配优先级”陷阱：当user表和db表同时存在同名用户时，MySQL按“主机匹配最长前缀”规则生效，而不是你想象的“精确匹配”。比如你删了'app_user'@'192.168.1.%'，却忘了清理残留的'app_user'@'%'，后者可能还挂着GRANT ALL PRIVILEGES ON *.*。

常见提权路径是：先通过SQL盲注拿到一个低权限账号的凭证 → 登录后执行SHOW GRANTS FOR CURRENT_USER → 发现该账号意外拥有FILE权限 → 用SELECT ... INTO OUTFILE写Webshell或读取/etc/passwd。

IntoDNS.ai

免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。

下载

• 定期运行SELECT User,Host,Super_priv FROM mysql.user WHERE Super_priv='Y'，确认只有DBA账号有SUPER权限
• 检查LOAD_FILE()、INTO OUTFILE、EXECUTE函数是否被禁用：SELECT @@secure_file_priv应返回NULL或明确路径，且该路径不可写
• 业务账号禁止授予GRANT OPTION，否则可自行给自己加权限
• 用REVOKE FILE ON *.* FROM 'app_user'@'%'显式回收，不要只依赖“没授过就等于没有”

盲注防御不能只靠预处理语句

预处理语句能防拼接型注入，但对盲注无效——因为盲注本身不依赖报错或回显，它利用的是SQL逻辑分支和数据库行为差异。比如SELECT IF((SELECT COUNT(*) FROM users)>100, SLEEP(3), 0)这种语句，即使用了?占位符，只要字段名、函数名、子查询结构是动态拼的，照样中招。

真正要拦住这类攻击，得在应用层做三件事：校验字段白名单、限制子查询嵌套深度、统一响应超时阈值。

• 对所有ORDER BY字段，用in_array($input, ['id', 'name', 'updated_at'])硬校验，拒绝任何不在列表中的值
• 禁止前端传入UNION SELECT、EXISTS、INFORMATION_SCHEMA等关键词，WAF规则里加regex: (unions+select|information_schema|exists)
• 数据库连接池设置wait_timeout=30，应用层对单次查询强制max_execution_time=2000（毫秒），超时即断开并记日志
• 对LIKE查询，统一用ESCAPE '\'并过滤输入中的%、_，避免通配符被滥用

权限审计最容易被忽略的细节

很多人跑完SHOW GRANTS FOR 'user'@'host'就以为万事大吉，但MySQL权限是叠加生效的：全局权限 + 数据库权限 + 表权限 + 列权限，只要任意一层开了INSERT，就算其他层全关了，也能写数据。

更隐蔽的是PROXY权限——它允许一个用户代理另一个用户登录，如果'monitor'@'%' PROXY 'admin'@'%'存在，攻击者拿下monitor就能获得admin的全部权限。

• 用SELECT * FROM mysql.proxies_priv查所有代理关系
• 执行SELECT User,Host,Db,Select_priv,Insert_priv,Update_priv,Delete_priv FROM mysql.db WHERE User != ''，逐行确认每个数据库级别的权限是否合理
• 对长期不用的账号，用DROP USER IF EXISTS 'backup_old'@'%'彻底删除，而不是只REVOKE
• 把mysql系统库的访问权限从SELECT降为USAGE，业务账号根本不需要读mysql.user