从源码泄露到Access数据库SQL注入：一个经典ASP网站后台渗透测试复盘

这个目标站点相当经典，遇到的漏洞也颇具代表性。整个过程素材简单，运气不错，恰好让我碰上了。

依旧是一个经典的门户网站。

碰巧在目录扫描中发现了 web.zip 文件。

不用猜，这很可能就是网站的备份源码文件了。

目前已知的信息是：后台登录页面在 admin/login.asp，并且我们拥有完整的源码文件。那么，就可以开始进行代码审计了。

没想到，我刚随机打开一个文件，就敏锐地察觉到这似乎是存在参数拼接的 SQL注入 漏洞。

if request("act")="edit" and request.QueryString("id")<>"" then
id=request("id")
sql="select * from admin where id="& SH_Clng(request.QueryString("id"))
rs.open sql,conn,3,2
if not rs.eof then
rs("aleave")=aleave
rs("admin")=admin
If Trim(Rs("Password"))<>Trim(Password) Then
rs("password")=md5(password,32)
End If
rs.update
end if
rs.close
elseif request("act")="add" then
sql="select * from admin where admin='"&admin&"'"
rs.open sql,conn,3,2
if (rs.eof and rs.bof) then
rs.addnew
rs("aleave")=aleave
rs("admin")=admin
rs("password")=md5(password,32)
rs.update
end if
rs.close
end if
set rs=nothing
conn.close
set conn=nothing
response.redirect "admin_admin.asp"

但这肯定是后台功能，我们需要找到前台的注入点才行。于是转头去审计目录外的 ASP 文件，比如 product.asp，about.asp，list.asp 等等。

随后对前台页面进行注入测试，然而，并没有成功。

于是用浏览器直接访问测试一下。

发现被拦截了。然后又翻了翻文件，发现整个前台的文件都存在字符拼接的SQL语句。于是全局搜索一下，看看到底拦截的代码在哪里。

代码中没有找到拦截逻辑，那么很可能是有 WAF（Web应用防火墙）在起作用。

手动尝试了单引号、空格、or，都被拦截了，但是 and 竟然可以通过。

手注还是有些费劲，于是借助AI写了个脚本来绕过过滤，然后就成功了。

发现后端数据库竟然是 Microsoft Access，这对我来说比较少见。尝试 --tables 枚举表名失败了。

正当我不知所措的时候，突然想到：我下载的是源码，是源码啊！那还费这么大劲搞注入干嘛，直接搜索数据库文件不就好了。

大脑思考片刻后，我恍然大悟，Access 数据库的后缀应该是 .mdb 或 .accdb。

没招了？嘻嘻，逗你们呢。其实一开始我就在翻找文件，在 data 目录里就有了发现。

当时看到后缀是 .asp，就直接划走了，实际上它就是一个Access数据库文件（ASP文件内嵌了数据库连接）。

找了个在线的Access数据库解析网站，直接看到了管理员账号和MD5加密的密码。

登录后台后发现，前台用了Kindeditor编辑器，没想到后台也统一用的这个编辑器组件。

于是让AI辅助审计了一下后台可能的RCE和文件上传漏洞。

结果发现，风险点都在编辑器的上传接口。AI报告说没有严格限制，可以上传ASP脚本文件。不过，自从某个AI模型版本更新后，其判断准确性一言难尽。

不过我发现允许列表中包含 asf 后缀，于是尝试上传ASP木马（伪装成asf文件），结果返回了500错误。

另一个非编辑器页面的附件上传接口同样返回500。该接口没有任何后缀限制，但直接上传 .asp 文件也失败了。

总结与思考

这次渗透测试的过程非常典型：从信息泄露（源码备份）开始，通过代码审计发现潜在的SQL注入点，绕过WAF进行验证，最终通过解析泄露的Access数据库文件直接获取后台权限。尽管在最后一步尝试文件上传Getshell时因未知的服务器端防护（可能是IIS配置或额外安全组件）而失败，但整个链路清晰地展示了一个老旧ASP+Access架构站点的常见安全风险。

对于开发者而言，这个案例的防护启示很明确：

1. 严禁源码备份文件可公开访问。
2. 对所有用户输入进行严格的参数化查询或过滤，避免SQL拼接。
3. 对上传功能进行严格的白名单验证，并在服务器端检查文件内容。
4. 定期进行安全审计和代码审计，及时发现此类经典漏洞。

如果你对这类实战漏洞分析感兴趣，欢迎到 云栈社区 的安全/渗透/逆向板块与更多安全爱好者交流探讨。