漏洞扫描能够识别的漏洞类型是
某电商平台去年被拖库，漏洞泄露了2000万条用户数据。扫描识别事后复盘，漏洞类攻击者利用的漏洞竟是一个三年前就公开的Struts2漏洞。安全团队不是扫描识别没做过扫描，而是漏洞类扫描器压根没认出那个老版本组件的变体。这事说明一个问题：漏洞扫描能识别什么，漏洞直接决定了你的扫描识别防线在哪漏风。
注入类漏洞是漏洞类扫描器最拿手的活。SQL注入、漏洞命令注入、扫描识别LDAP注入，漏洞类原理都差不多——用户输入被当成代码执行了。漏洞扫描器怎么判断？扫描识别它往参数里塞单引号、分号、漏洞类睡眠函数，看数据库报错不回显、响应时间变不变。比如一个登录框，输入' OR 1=1 --，页面直接抛出MySQL语法错误，这就算抓到了。但有意思的是，现在很多扫描器对二次注入、存储型注入的识别率惨不忍睹。为什么？因为payload存进数据库后，触发点可能在后台管理页面，扫描器爬不到那个路径。我见过一个案例，某CMS的评论功能存在存储型XSS，扫描器跑了三遍都显示安全，后来人工在后台审核列表里点了一下，弹窗了。
跨站脚本（XSS）的识别同样分三六九等。反射型XSS一抓一个准，扫描器发个<script>alert(1)</script>，看响应里有没有原样返回。DOM型XSS就麻烦多了，payload根本不经过服务器，全在浏览器里蹦跶。扫描器得模拟浏览器执行JS，还得跟踪DOM树变化。很多开源扫描器这块是短板，误报率能飙到40%以上。某金融客户曾抱怨，扫描器报了200个XSS，安全工程师手动验证了一星期，真漏洞只有7个。
文件包含和路径遍历属于“看运气”的类型。扫描器会尝试../../etc/passwd这类payload，但能不能成功取决于服务器配置。Windows和Linux的路径分隔符不一样，编码方式也五花八门。更头疼的是，有些应用把用户输入拼进文件路径后做了白名单过滤，但过滤逻辑有缺陷。扫描器如果只会发标准payload，根本测不出来。我见过一个PHP应用，参数是?page=about，扫描器试了?page=../../etc/passwd，返回空白页。安全研究员手动试了?page=....//....//etc/passwd，成功了。扫描器没这个变体库。
配置错误和敏感信息泄露，扫描器反而比人靠谱。比如目录列表开启、默认后台路径、备份文件残留、HTTP头泄露服务器版本。这些不需要复杂逻辑判断，发个请求看响应就行。但问题在于，扫描器不知道哪些信息算“敏感”。某次扫描报告里列了/phpinfo.php可访问，运维说“这页面没敏感信息啊”。点开一看，里面暴露了数据库连接串的明文密码。扫描器只标记了“信息泄露”，没标严重级别。
逻辑漏洞？扫描器基本抓瞎。比如越权访问、验证码复用、支付金额篡改。这些漏洞没有固定payload，依赖业务上下文。一个修改密码的接口，扫描器不知道“用户A能不能改用户B的密码”这个语义。它只能测参数有没有SQL注入、有没有XSS。所以很多渗透测试报告里，逻辑漏洞那一栏永远写着“需人工测试”。
组件漏洞的识别靠指纹比对。扫描器爬页面、读JS文件、看HTTP响应头，拼凑出你用了jQuery 1.7、Struts 2.3.15、Log4j 2.14。然后去CVE库匹配。这招对已知漏洞有效，但遇到版本号被篡改、或者组件被二次打包就废了。某次扫描显示“未发现Log4j漏洞”，结果攻击者用JNDI注入打穿了。因为那个应用把log4j-core的版本号改成了2.17.0，实际代码还是2.14.1。
说到底，漏洞扫描是个概率游戏。它能识别的是那些有固定模式、有已知payload、响应特征明显的漏洞。识别不了的是需要业务理解、多步交互、或者压根没被收录的0day。别指望扫描器给你一个干净的安全报告，它更像一个粗筛子，筛掉80%的明显问题，剩下20%的硬骨头，还得靠人啃。