web漏洞扫描主要面向什么进行漏洞扫描
作者:焦点 来源:综合 浏览: 【大 中 小】 发布时间:2026-10-17 06:07:23 评论数:
Web漏洞扫描器抓的洞扫洞扫最多的,其实是描主面向描HTTP请求里那些“没被正常处理”的输入点。比如一个登录框,什进你输个 ' OR 1=1 --,行漏扫描器立刻会标记“疑似SQL注入”。洞扫洞扫它不关心你后端是描主面向描MySQL还是Oracle,也不管你用了什么ORM框架,什进它只看请求发出去之后,行漏服务器回应的洞扫洞扫状态码、响应时间、描主面向描报错信息有没有异常变化。什进这是行漏最底层的逻辑——扫描器本质上是个“差异探测器”。
具体扫什么?洞扫洞扫我拆开说。第一类,描主面向描URL参数。什进像 ?id=123 这种,扫描器会把它替换成 ?id=123'、?id=123 AND 1=1、?id=123%00,然后对比原始响应和篡改后的响应长度、HTTP头、页面内容。如果返回了数据库报错,或者页面内容突然变多/变少,它就报一个洞。真实场景里,很多老系统的分页参数、搜索关键词、排序字段都是重灾区。
第二类,表单字段。POST请求里的每个、
第三类,HTTP请求头。User-Agent、Referer、X-Forwarded-For、Cookie,这些地方经常被忽略。有些WAF只检查URL参数,不检查Header,扫描器就往 X-Forwarded-For: 127.0.0.1' AND SLEEP(5)-- 里塞注入语句。如果服务器响应延迟了5秒,说明存在基于时间的盲注。这个手法在真实渗透里很常见,扫描器只是自动化了重复测试的过程。
第四类,文件上传点。扫描器会尝试上传 .php、.jsp、.asp 后缀的文件,或者把 shell.php.jpg 这种双后缀发过去。它不判断文件内容是否真的能执行,只看服务器返回的是“上传成功”还是“文件类型不允许”。有些扫描器还会检查上传后的路径是否可访问,比如返回的JSON里带了 url: /uploads/xxx.php,它就立刻发个GET请求确认是否解析。
第五类,API接口。现在前后端分离的项目多了,扫描器开始重点扫 /api/v1/user?id=1 这种RESTful端点。它会尝试把GET换成POST、PUT、DELETE,看看有没有未授权访问。我遇到过某电商的 /api/order/123,GET请求需要token,但DELETE请求居然不需要,扫描器直接报了个“越权删除”。这种逻辑漏洞,传统扫描器不一定能发现,但新一代的会做HTTP方法枚举。
还有一类容易被忽略的:JSON和XML请求体。比如 { "username":"admin","password":"123"},扫描器会把值替换成 { "$ne": null} 试试NoSQL注入,或者塞个XXE实体进去。很多扫描器对JSON的支持不如表单好,经常漏报,所以实际用的时候得手动补测。
扫描器不扫什么?它不扫业务逻辑。比如“修改密码时没验证旧密码”、“订单金额可以为负数”、“优惠券可以无限叠加”,这些它看不出来。它只扫那些有明确payload模式、能通过HTTP响应差异判断的漏洞。所以别指望一个扫描器能覆盖所有风险,它就是个高效的“输入点探测器”,把那些最明显的注入、跨站、文件包含、目录遍历先筛一遍。
最后说个实际观察:很多团队买了扫描器,配个URL就开始跑,结果报告里全是“低危”的Cookie缺失HttpOnly、X-Frame-Options没设。真正的高危——比如某个参数存在布尔盲注——反而因为扫描器payload不够全或者被WAF拦截而漏掉。所以用扫描器得会看报告,也得会调策略。它是个工具,不是答案。
```