asp漏洞

去年帮一个朋友看他的企业站，刚打开首页我就皱了眉头——URL里明晃晃挂着 ?id=12。随手加了个单引号，页面直接甩出一段 ODBC 错误，数据库路径、表名全在里面。这就是典型的 ASP 注入漏洞，二十年了，还在互联网上天天发生。

ASP 本身不算漏洞，问题出在写代码的人怎么用它。早年学 ASP 的人大多是从 Request 对象直接取值，然后拼进 SQL 字符串里。比如登录验证，代码写出来是这样的：

sql = "SELECT * FROM users WHERE name='" & Request.Form("name") & "' AND pwd='" & Request.Form("pwd") & "'"

用户输入什么，它就拼什么。你在密码框里输入 ' OR '1'='1，这条 SQL 就变成永真条件，直接绕过登录。更狠的用分号执行多语句，或者用 EXEC xp_cmdshell 提权到系统命令。2005 年前后那批被挂马的政府站、学校站，九成都是这么沦陷的。

我见过一个最离谱的案例。某地方人才网，搜索框过滤了单引号，但没过滤 % 和 _。攻击者用 LIKE 模糊匹配配合 UNION SELECT，把管理员表整个拖了下来。网站后台密码是明文存储的，连撞库都省了。这事发生在 2019 年，不是 2003 年。

为什么 ASP 漏洞这么顽固？两个原因。一是存量太大。国内大量中小企业站、政务旧系统、甚至一些医院的挂号页面，还在跑 Windows Server 2003 + IIS 6 + Access 或 SQL Server 2000。这套环境本身不强制参数化查询，开发者图省事就用字符串拼接。二是维护断层。当年写这些代码的人早转行了，接手的运维只求网站能打开，根本不看代码。

修复方法其实不复杂。参数化查询是首选，ASP 里用 Command 对象的 Parameters 集合，把用户输入当参数传，不要当 SQL 文本拼。如果实在改不动老代码，至少做三层过滤：用 Replace 干掉单引号、分号、注释符；限制输入长度；把数据库账号降权，别用 sa 连库。我见过一个运维直接在 IIS 里装了个 ISAPI 过滤器，拦截所有带 SQL 关键字的请求，虽然粗暴但确实挡住了大部分自动化扫描。

还有个容易被忽略的点：错误回显。很多 ASP 站默认开详细错误，一报错就把 SQL 语句和物理路径全吐出来。攻击者连盲注都不用试，直接看着报错调整 payload。把 web.config 里的 customErrors 打开，或者至少在 IIS 里关掉向客户端发送详细错误，能砍掉一半的信息泄露。

说到底，ASP 漏洞不是技术难题，是历史债。新项目没人用 ASP 了，但旧系统还在跑。只要那些 Request 直接拼 SQL 的代码还在服务器上，漏洞就在。你扫不扫，它都在那里。