sql注入漏洞的入漏测试流程，说白了就三步：探、测试验、流程掏。入漏别把这事儿想得太玄乎，测试实际渗透测试里九成时间都耗在第一步上。流程

第一步，入漏探。测试你得先找到一个可能跟数据库交互的流程入口。URL参数、入漏搜索框、测试登录表单、流程排序字段，入漏这些地方都可能是测试突破口。我见过不少新手上来就对着一个静态页面狂打sqlmap，流程那纯属浪费时间。真正有效的做法是抓包看请求，把参数值改成一个单引号，观察响应有没有变化。比如有个电商站，商品详情页的id参数是数字，你把id=1改成id=1'，页面崩了，报错信息里出现了MySQL语法错误——恭喜，这就是个活生生的注入点。

第二步，验。确认了有异常还不够，得验证这到底是不是sql注入，以及属于哪种类型。这里有个小技巧，用逻辑判断代替盲目猜测。拿刚才那个id参数举例，构造id=1 and 1=1，页面正常；改成id=1 and 1=2，页面空白。这一黑一白，基本就能断定是数字型注入。要是字符型，你得注意闭合方式，单引号、双引号、括号，都得试一遍。我记得有一次测一个政务系统，参数被套了三层括号，硬是试了二十多分钟才找到闭合点。

第三步，掏。这一步才是真正拿数据。但别急着上sqlmap，先手工确认注入深度。用order by语句判断字段数量，order by 3正常，order by 4报错，好，就三个字段。接着用union select把回显点找出来，看看哪个字段的数据会直接显示在页面上。这一步特别磨人，但也是最有意思的时候——你就像在跟数据库玩捉迷藏，找到了回显点，等于拿到了数据库的钥匙。

实际测试中，我习惯用两种思路并行。一种是纯手工，适合小范围快速验证，能精确控制payload，不容易触发WAF报警。另一种是工具辅助，sqlmap这种自动化工具适合大规模扫描，但噪音太大，而且目标站点有防护的话，很容易被拦。我的做法是先用工具跑一遍广度，再用手工聚焦深度。有一次测一个金融平台的查询接口，sqlmap跑了半小时啥也没发现，我手工试了个时间盲注，居然中了——因为那个接口把报错信息全部吞掉了，但响应时间有明显差异。

还有个容易踩的坑：别忽略POST请求里的参数，也别只盯着业务逻辑明显的字段。Cookie、Referer、X-Forwarded-For这些HTTP头都可能被拼接进SQL语句。我见过一个奇葩案例，某后台管理系统的登录日志功能，把用户代理字符串直接写进了查询条件，结果整个日志模块成了注入乐园。

最后提醒一句，测试环境要跟生产环境隔离。别为了图方便，直接拿线上库做实验。出了事故，背锅的可是你自己。流程这东西，说复杂也复杂，说简单也简单——关键在细心和耐心，多试几次，总能找到那个漏网之鱼。