如何处理SQL注入敏感源_记录所有不安全的SQL请求

SQL注入检测需基于SQL解析层或语义分析，而非日志关键词匹配；应记录未参数化拼接的上下文（如调用栈、模板化SQL），并配套白名单与误报反馈机制。SQL注入检测不能靠日志关键词匹配只在日志里搜 ' OR 1=1 或 UNION SELECT 这类字符串，漏报率极高。攻击者用 URL 编码、大小写混用、注释符绕过、空格替换成 %09（制表符）等手法，让原始 payload 看起来完全不像“典型注入”。真正有效的检测必须落在 SQL 解析层或执行前的语义分析上。应用层做简单正则拦截，只能拦住脚本小子，对稍有经验的攻击者无效WAF 规则若只依赖特征串，容易被 SEL/**/ECT 或 select%091 绕过真正可信的判断点：数据库驱动是否把用户输入当字面量处理？有没有走预编译？记录不安全请求的前提是识别出“未参数化的拼接”不是所有含单引号的请求都该记——关键看它是否出现在 query 字符串拼接中且未被转义或绑定。比如 Python 的 cursor.execute("SELECT * FROM users WHERE id = " + user_id) 是高危；而 cursor.execute("SELECT * FROM users WHERE id = %s", [user_id]) 即使 user_id 是 "1 OR 1=1"，也不会触发注入，也不该进“不安全请求”日志。Java 中检查是否调用了 Statement.execute() 而非 PreparedStatement.execute()PHP 中注意 mysql_query()（已废弃）、mysqli_query() 直接拼接，而非 mysqli_prepare()Node.js 的 mysql2 库里，connection.query("SELECT ... " + input) 才危险，connection.execute() 自动参数化则安全记录内容必须包含可追溯的上下文，否则日志等于没记光记下 SELECT * FROM users WHERE name = 'admin'-- 没用。没有调用栈、没有 HTTP Referer、没有对应 controller/action 名、没有绑定参数的实际值，你根本没法定位是哪个业务接口、哪行代码、哪个开发写的这个拼接逻辑。 有道翻译AI助手 有道翻译提供即时免费的中文、英语、日语、韩语、法语、德语、俄语、西班牙语、葡萄牙语、越南语、印尼语、意大利语、荷兰语、泰语全文翻译、网页翻译、文档翻译、PDF翻