SQL注入攻击已经存在超过二十年，应用但至今仍在OWASP Top 10中占据一席之地。注入我见过太多开发者在写SQL查询时直接拼接用户输入，漏洞也见过安全工程师拿着商业扫描器跑完整个应用却只得到一堆误报。检测计实这套工具的工具设计初衷很简单：用最直接的方式检测注入点，不绕弯子。应用 工具核心逻辑分为三个模块。注入第一个是漏洞请求构造器，它负责把普通HTTP请求中的检测计实参数值替换成预设的检测载荷。第二个是工具响应分析器，通过比较正常响应与异常响应的应用差异来判断是否存在注入。第三个是注入漏洞利用验证器，当分析器给出可疑信号时，漏洞它会尝试用更精确的检测计实payload确认漏洞是否真实存在。 检测载荷的工具设计需要讲究。我最初只用了单引号和布尔条件，但很快发现绕过率太高。后来加入了时间盲注的payload，比如`AND SLEEP(5)`，以及基于报错的payload，像`AND extractvalue(1,concat(0x7e,database()))`。每种payload都配有不同的检测策略，因为有些应用会过滤关键字，有些则对特殊字符做了转义。 响应分析器是整个工具的灵魂。我在实现时采用了三层判断机制。第一层看响应时间，如果时间盲注的payload让响应延迟了明显超过正常值，直接标记可疑。第二层看内容差异，用相似度算法对比正常响应和注入响应的HTML结构，差异超过阈值就触发告警。第三层看状态码和错误信息，如果响应中出现SQL语法错误提示或者HTTP 500，立刻记录。这三层判断是并行执行的，任何一个触发都会进入验证阶段。 验证器的作用是过滤误报。很多情况下，响应差异只是应用本身的不稳定行为，并非SQL注入。验证器会使用完全不同的payload类型重新测试同一个参数。比如第一次用单引号触发错误，第二次就用`AND 1=1`和`AND 1=2`分别请求，对比两次响应的差异。如果这两次响应有明显区别，基本可以确定注入点存在。 这个工具在真实环境中测试时发现了一个问题——对JSON格式的POST请求支持不够好。很多现代web应用用JSON传参，而传统扫描工具只处理表单格式。我重写了请求构造器，让它可以解析嵌套JSON结构，并在字符串值、数字值甚至键名中注入payload。这个改进让工具的实际检出率提升了约三成。 工具还内置了一个轻量级的爬虫模块，用于从目标站点提取所有带参数的URL。爬虫不追求抓取全站，只关注那些包含query string或者表单提交的链接。这样能节省大量时间，因为SQL注入只会出现在参数处理环节。爬虫还会自动过滤掉静态资源路径和退出链接，避免浪费时间在无意义的页面上。 命令行界面是必须的，但我也加了简单的HTML报告输出。报告会列出每个可疑参数的请求示例、payload类型、响应差异摘要和验证结果。方便开发人员直接复制请求到Burp Suite里做进一步测试。整个工具用Python写成，依赖库只有requests和beautifulsoup4，部署起来不费劲。 最后说点个人感受。写这个工具最困难的部分不是检测逻辑，而是如何平衡检出率和误报率。太敏感的规则会把所有参数都报成漏洞，太保守又会漏掉真实风险。我调整了三十多版阈值参数，才找到一个相对合理的平衡点。实际使用中，这个工具更适合作为日常开发阶段的辅助检查，而不是替代专业渗透测试。毕竟，再好的工具也只是辅助，真正的安全还需要开发者从编写第一条SQL语句时就保持警惕。