上个月帮一个做外贸的站漏朋友看他的ASP老站，刚打开首页就发现不对劲——URL里带了个奇怪的洞扫参数，页面底部还多了一行iframe。描工查了下日志，站漏有人用工具批量扫目录，洞扫已经试了上千次。描工他那站点跑在Windows Server 2003上，站漏IIS 6.0，洞扫代码是描工十年前的ASP。这类站现在不多了，站漏但一旦存在，洞扫漏洞基本是描工“裸奔”状态。

ASP网站漏洞扫描工具，站漏说白了就是洞扫专门针对Active Server Pages环境做安全检测的软件。跟扫PHP或Java的描工工具有点不一样，它得懂IIS的脾气，知道ASP里哪些函数容易出事。比如Request对象直接取参数拼SQL，或者用FileSystemObject操作文件时没过滤路径，这些都是老ASP的经典毛病。

几个我实际用过的工具

Acunetix算是最早支持ASP扫描的商业工具之一。它的优势是爬行能力不错，能顺着链接把整个ASP站点的结构摸出来。我试过拿它扫一个带Access数据库的站，不到十分钟就报出SQL注入点，还附带了验证用的payload。不过它的报告太啰嗦，满屏都是“可能存在的风险”，得自己筛。

Netsparker（现在叫Invicti）对ASP的兼容性也还行。它有个特点：证明漏洞时不会真的去删数据，而是用时间盲注或者布尔盲注来确认。这对生产环境比较友好。有次我扫一个客户的老ASP后台，它发现了一个上传漏洞，但只传了个txt文件上去，没搞破坏。

开源方面，OWASP ZAP能扫ASP，但得手动配一下。默认的扫描策略对ASPX更友好，纯ASP的站点需要调整规则。我一般会加个自定义的fuzz列表，专门测那些.asp结尾的路径，比如`/admin/login.asp`、`/inc/conn.asp`这种常见文件。

手动配合工具才靠谱

光靠工具扫，误报和漏报都躲不掉。我的习惯是先用工具跑一遍，拿到可疑URL列表，然后手动用浏览器或者curl去试。比如工具报`/news.asp?id=1`有注入，我会先加个单引号看报不报错，再用`and 1=1`和`and 1=2`对比返回内容长度。ASP的报错信息通常很直白，直接告诉你“Microsoft OLE DB Provider for ODBC Drivers 错误 ‘80040e14’”，连数据库类型都省得猜了。

还有一类漏洞工具经常漏掉：ASP里的包含文件漏洞。比如``这种，如果head.asp里又动态包含了用户可控的路径，就能搞出文件包含。扫描器一般只测URL参数，对这种服务器端包含的检测能力很弱。我遇到过好几次，工具没报，手动测出来的。

扫出来之后怎么办

修ASP漏洞比修PHP麻烦。PHP改个函数就行，ASP经常要动整个数据访问层。比如SQL注入，最彻底的办法是把所有拼接SQL的地方改成参数化查询，但老ASP代码里到处是`"select * from users where id=" & request("id")`这种写法，改起来量大。退而求其次就是加个过滤函数，但容易漏。

我一般建议客户先上WAF挡一道，比如ModSecurity配IIS，或者用云WAF。然后按漏洞等级排优先级：能直接拿webshell的（上传、包含）先修，注入和XSS往后放。最后才是代码重构。

说到底，ASP网站漏洞扫描工具只是个起点。它帮你找到入口，但进去之后怎么走，还得靠人对IIS和ASP的理解。那些还在跑ASP的老站，要么赶紧迁走，要么就老老实实定期扫、手动测、打补丁。别等被人挂了马才想起来查日志。