上个月做一次授权测试客户丢过来一份资产清单里面躺着七八个只有内网才能访问的遗留系统。开发同事很不屑说这些都是十年前的ASPAccess早没人维护了随便点点就行。结果半天不到我就在其中一个系统里拿到了数据库全量用户表。这种场景在今天一点都不稀奇——越是没人愿意碰的老系统越容易成为整个内网最脆弱的入口。这篇把ASP应用这条线上的几个攻击面完整梳理一遍HTTP.SYS内核层漏洞、短文件名的信息泄漏、IIS文件解析差异、Access注入的猜解思路以及最终数据库文件泄露的链路。这不是鼓励谁去搞破坏而是想说明一个安全测试者应该怎么系统化地看待老技术栈防守方又该从哪里下手补窟窿。所有方法只在书面授权的范围内讨论和使用这是我做这一行多年的底线。1. 存量ASP站点为什么成了安全测试的重点对象1.1 内网资产清单里的老古董并不少很多政企内网里依然跑着大量ASPAccess的系统。它们可能是2005年到2010年之间由外包团队开发的当时的主流技术栈就是ASP、Access、MSSQL部署在Windows Server 2003或2008上。这些系统承载着员工管理、工会报销、内部投票、旧版OA流程之类的业务数据量不大但一直没有被正式下线。没下线的原因很现实业务还在用数据迁移成本高老系统里的逻辑没人说得清楚开发商可能早就散伙了。于是这些系统就像内网里的老房子外表看着破但水管电线全在里面出了问题也没人敢动。从安全测试角度讲这类系统恰恰是最有料的目标。它们往往满足三个条件暴露面广、维护停滞、防护薄弱。开发阶段的代码质量问题几乎原样保留补丁长期不更新WAF和日志审计系统大概率也没覆盖。很多测试者一看到ASP就下意识觉得太老了没什么可测真正的高手反而知道老不等于安全老通常等于漏洞密度高。1.2 老旧代码的安全债都堆在哪里ASPAccess系统的代码问题我基本可以总结成几类几乎每次测试都能撞上一两种SQL语句大量使用字符串拼接用户输入直接拼进查询连转义都懒得做。管理员密码要么明文存储要么只用简单MD5后台登录没有任何失败次数限制。上传功能只校验扩展名白名单实际运行时却靠IIS的解析逻辑兜底。管理入口没有限制来源IP也没有双因素认证后台地址往往靠弱口令就能进。目录权限配置随意Web根目录下直接放数据库文件、备份文件、连接文件。数据库连接字符串写在conn.asp里路径常常是相对路径一旦文件被读取数据库文件位置直接暴露。这些都不是什么高级漏洞但组合在一起就能形成完整的攻击链。关键是很多内网运维人员觉得系统在内网外面打不进来于是补丁不打、权限不收、日志不看等于把门锁坏了还不换。1.3 从单个漏洞到执行链路的测试视角单看一个漏洞可能就是个中低危。比如短文件名枚举无非是泄露几个文件名Access注入点可能只是某个搜索框报错。但在安全测试里真正有价值的不是孤立的漏洞点而是能不能把它们串成一条执行链路。拿ASP站点来说经常出现这样的链路短文件名定位到了后台路径后台弱口令登录成功上传功能存在扩展名过滤缺陷配合IIS文件解析差异执行脚本最终读取连接文件或直接下载Access数据库文件。整条链走完数据就到手了。后面几章就按这条链的顺序逐个展开。2. HTTP.SYS内核驱动层的攻击面与测试边界2.1 HTTP.SYS在IIS架构里的位置HTTP.SYS是Windows内核里的HTTP协议监听驱动所有发给IIS的HTTP请求不管后面是ASP还是ASP.NET都会先经过它。可以把它理解成大楼门口的物业门卫访客先到门卫登记门卫确认身份后再放行到具体楼层。IIS的用户态工作进程就是楼里的那些办公区域。这个设计本来是微软为了提升性能把HTTP协议解析放到内核态承载大量并发请求时不那么容易被打垮。但代价是内核态出漏洞影响的是整个操作系统而不是某一个站点。HTTP.SYS一旦被攻破攻击者获得的是系统层面的控制能力比单纯入侵一个站点的危害大得多。2.2 MS15-034的漏洞成因和影响范围2015年微软发布的安全公告MS15-034对应CVE-2015-1635问题就出在HTTP.SYS对Range请求头的处理上。Range头本来是HTTP协议里用于分段下载的客户端可以指定要获取文件的哪一段字节。问题在于当Range头里的范围值被精心构造到一个极端长度时HTTP.SYS内部计算时发生整数溢出导致系统崩溃严重时存在远程代码执行的可能。影响范围覆盖当时的Windows 7、Windows Server 2008 R2、Windows Server 2012等主流系统只要开启了IIS就等于暴露了这个攻击面。这一漏洞刚公开的时候安全圈甚至把它当成快速打崩目标的经典手段。项目内容漏洞编号CVE-2015-1635安全公告MS15-034受影响组件Windows HTTP.SYS 内核驱动漏洞成因Range头边界计算整数溢出潜在危害拒绝服务、可能的远程代码执行修复补丁KB30425532.3 授权测试里的非破坏性验证方式测试HTTP.SYS漏洞时第一原则是别把目标打崩。因为某些利用请求会让系统直接蓝屏重启在业务系统上这么测性质就变成了人为中断服务哪怕是授权测试也要尽量避免。我推荐的做法是优先确认目标系统的补丁状态。在Windows环境下可以用系统命令查询补丁编号如果发现KB3042553没有安装基本可以判定存在漏洞。其次是看服务器的具体版本和补丁更新日期年代久远的系统通常都逃不掉。只有在测试窗口明确、目标允许且做好预案的情况下才考虑用非破坏性请求做状态码验证。如果看到响应头里有异常的日期字段、状态码为416就需要进一步人工确认。验证方式破坏性适用场景查询补丁编号无首选快速判断检查系统版本和补丁日期无信息收集阶段构造特殊Range请求可能导致蓝屏仅在授权且可承担风险时2.4 防守方怎么补这个洞最直接的修复就是安装补丁这个没有任何可商量的余地。很多内网系统常年不更新就是因为怕重启影响业务。我的建议是给这类系统单独排一个维护窗口按批次打补丁优先处理对外开放、有真实业务数据的服务器。另外在网络边界和IIS日志层面可以增加对畸形Range头请求的告警。如果内网某个IP频繁发送带超长Range头的请求说明有人在扫描或者尝试利用这个漏洞。这种流量特征非常明显日志里很容易发现。3. 短文件名探测Windows文件系统的信息泄漏3.1 8.3短文件名的来龙去脉Windows NTFS文件系统默认会给每个长文件名生成一个8.3格式的短文件名这是为了兼容老版本的16位程序。生成规则基本是把长文件名截断成前6个字符加上波浪号和数字序号扩展名保留前3个字符。比如长文件名短文件名ThisIsALongFileName.aspTHISIS~1.ASPadmin_login_page.aspADMINL~1.ASPdatabase_backup_2023.mdbDATABA~1.MDB问题在于短文件名是文件系统自动生成的不是应用开发者主动控制的。很多开发者根本不知道Web目录下有这个隐藏的后门名。而这个名字一旦暴露等于把文件存在与否、文件名前几个字符都没穿衣服地亮了出来。3.2 IIS下如何通过通配符枚举短文件名在IIS环境里短文件名泄漏问题的关键是可以被远程探测。具体原理是IIS在处理包含通配符的URL请求时会把这些路径交给文件系统做模糊匹配而不同的匹配结果会返回不同的HTTP状态码。安全测试中常见的思路是构造包含*~1*这种模式的请求反复替换前面的字符根据响应差异逐步还原出完整的短文件名。举个例子如果请求/A*~1*/.aspx返回的状态码和/B*~1*/.aspx有区别就能判断出短文件名是否以A开头。用这种方式可以在不知道具体文件名的情况下逐个字符把短名爆破出来。这个手段在找不到后台地址的时候特别有用。传统目录爆破靠字典硬撞效率低命中率也看运气。短文件枚举等于直接从文件系统层面确认了文件的存在性和前缀比字典爆破精准得多。我在一次测试里就是通过短文件名定位到了MANAGE~1.ASP后台入口瞬间暴露比扫描器跑了几个小时的字典都有效。请求模式可能的状态码含义/前缀*~1*/.aspx404短文件名存在/前缀*~1*/.aspx400短文件名不存在或不可访问/前缀*~1*/.aspx403.14目录列表被禁止3.3 实战中的误报与限制短文件探测不是百分百可靠实际使用中会遇到不少坑。第一IIS的不同版本、不同补丁状态对通配符请求的处理方式有差异返回码未必完全一致。第二请求频率如果太高老服务器可能会出现连接超时或日志暴涨容易打草惊蛇。第三短文件名会存在多个重名序号比如多个文件的前6个字符相同需要把序号也枚举出来。我给的建议是扫描结果一定要人工复测。工具跑出来显示某个短文件名存在至少手动再发两次同样的请求确认响应是否稳定。同时把扫描的并发数调低控制在每秒几个请求的水平既能保证准确率也不会对目标造成压力。3.4 关闭短文件名的一整套操作从防守角度看最彻底的方案是关闭NTFS的8.3短文件名生成功能。以管理员身份执行fsutil behavior set disable8dot3 1注意这个命令只对新创建的文件生效已经存在的文件仍然保留短文件名。要把已有文件也处理掉可以用fsutil 8dot3name strip /s:C:\你的网站目录这个操作会遍历指定目录并移除所有文件的短文件名不会删除文件本身。执行之前建议先在测试环境跑一遍确认没有程序依赖旧短文件名访问文件。IIS层还能再加一道请求过滤对URL中包含*~1*特征的请求直接返回403从访问入口切断探测行为。4. 文件解析差异IIS历史上那些上传变脚本的坑4.1 IIS 6.0时代的两个经典解析问题IIS 6.0的解析漏洞是ASP站点测试绕不开的话题即便今天系统已经升级到IIS 7老站点的配置方式可能还残留着旧习惯。第一个经典问题是分号截断。服务器解析文件名时遇到分号会忽略后面的内容比如把文件命名为test.asp;.jpg实际访问时会被当作test.asp来执行。于是攻击者只需要上传一个内容为脚本的图片文件改成分号加后缀的名字就能让服务器把它当ASP脚本跑。第二个经典问题是特殊目录解析。如果上传目录名以.asp结尾比如/upload.asp/该目录下所有文件都会按ASP脚本解析不管你放的是图片还是文本。这个问题的实质是IIS 6.0的应用程序映射逻辑把目录名和脚本引擎绑定在了一起。IIS版本解析问题触发条件IIS 6.0分号截断文件名包含;IIS 6.0.asp目录解析目录名以.asp结尾IIS 7.0/7.5FastCGI解析边界配置了通配符处理程序4.2 IIS 7.x的FastCGI解析边界漏洞到了IIS 7.0和7.5解析漏洞换了形态。当服务器通过FastCGI方式处理脚本请求时如果访问一个类似/test.jpg/x.asp的路径而x.asp文件并不存在某些配置下FastCGI会把前面的test.jpg当作脚本直接执行。这意味着上传一张内容为服务器脚本的图片加上一段伪装的路径就能触发执行。这类问题的本质是配置错误不是IIS内核缺陷。很多管理员在配置处理映射时图省事把所有请求都交给了脚本引擎结果静态文件也被拖下水。测试时遇到这种情况我会特意访问上传文件的路径在文件名后面追加一段不存在但以.asp结尾的路径看返回内容是否异常。4.3 自查上传接口的实操思路对于安全测试者来说检查一个ASP站点是否存在文件解析问题不需要一上来就上传攻击脚本。先把上传接口的响应看一遍上传一个正常图片保存后观察文件名是否被服务器重写、扩展名是否原样保留、上传目录是否有脚本执行权限。再结合IIS版本针对性地试一下分号、双扩展名、特殊目录名观察服务器处理差异。从防守方的角度最稳妥的加固方式是上传目录单独设置禁止脚本执行权限上传后使用随机文件名并去掉特殊字符禁止包含分号、反斜杠等危险字符如果还在用老版本IIS尽早迁移升级。这些措施加在一起能防住绝大多数解析类攻击。5. Access注入的猜解逻辑没有系统库也能摸到数据5.1 Access与MySQL在注入场景里的本质差异很多新入行的测试者习惯了MySQL的information_schema一到Access就懵了因为Access数据库根本没有系统表可以查询表名和字段名。它整个数据库就是单个.mdb或.accdb文件也没有堆叠查询一条SQL语句里只能执行一次查询。这些限制直接决定了Access注入的测试风格靠猜。对比维度MySQLAccess系统信息表information_schema无堆叠查询支持不支持注释符-- 、#、/* */-- 、%00有限制数据来源在线查询可下载整个库文件5.2 联合查询第一步确定字段数再猜表名Access注入可以用联合查询来注数据但联合查询要求后面的SELECT语句列数与前面对齐。通常会用order by逐级测试字段数当排序序号超过实际列数时报错从而确定当前查询有几列。拿到列数后就可以拼union select但Access的联合查询要求from后面的表名必须真实存在所以必须先猜表名。猜表名的常见思路是从业务相关的关键词入手比如admin、user、news、product。判断表是否存在可以用exists(select * from 表名)返回正常说明表存在报错说明表不存在。依此类推再猜字段名。整个流程听上去笨但确实有效。5.3 布尔盲注和偏移注入的适用场景有些ASP站点的页面不显示数据库报错联合查询的显示位也拿不到这时候就要走布尔盲注。Access盲注的常见判断逻辑是用条件判断构造出真和假两种响应比如and (select count(*) from admin)0如果页面显示正常说明admin表存在且记录数大于0。接着逐字符猜用户名和密码效率低但可靠。偏移注入则是另一种思路当表名猜到了但字段名猜不出来时可以直接用表名.*把整张表的字段一次性带出来。它的原理是当前查询列数确定后用union select 1,2,3,...,admin.* from admin这种方式用admin.*填补剩余列位这样不需要知道具体字段名也能拿到整表数据。当然偏移注入对列数有要求列数不够时还要用多个表的*来凑成功率不是100%。5.4 宽字节注入为什么在ASP里频发老ASP系统大量使用GBK编码这给注入测试带来了一个特殊变量——宽字节注入。原理并不复杂GBK编码中一个汉字占两个字节当转义函数在处理用户输入时只转义单字节的引号攻击者可以在引号前面加上一个字节让引擎把引号和它前一个字节当作一个汉字来吞掉原本的转义符也就不再生效了。这个手法在%df%27这种经典组合里很常见也是为什么单纯对ASP站点做关键字过滤往往防不住注入。5.5 Access侧的防御落地方案防守方要应对Access注入最根本的是把参数化查询用起来。ASP里处理SQL语句如果还在拼字符串就要重构成Command对象参数占位符的方式。同时要给数据库连接账号最小权限应用连接Access文件时尽量使用只读账号。另外WAF规则不能只盯着常见关键字还要覆盖宽字节编码、大小写混写、注释符替代这些绕过手法。6. 数据库文件泄露的路径与组合利用复盘6.1 .mdb文件为什么会落到攻击者手里Access数据库是文件型数据库整个库就是一个物理文件。由于历史原因很多老系统的.mdb文件就直接放在Web站点根目录或子目录下路径写在conn.asp或db.asp的连接字符串里。攻击者只要拿到这个路径直接在浏览器里请求/xx/database.mdb就能把整个数据库下载下来连注入都省了。通往这个路径的常见入口有几个。第一是连接文件本身被泄露比如通过备份文件下载、目录遍历、短文件名枚举找到conn.asp第二是数据库文件名暴露在报错信息或页面源码注释里第三是某些后台功能提供了数据库备份下载但备份文件没有做随机化处理。路径泄露后的下载还需要一个条件Web服务器对该目录允许静态文件访问。很多老管理员觉得.mdb不是脚本文件放在站里没什么风险结果攻击者下载后本地打开整库数据不费吹灰之力。6.2 一条典型的组合利用复盘把前面的几个技术点串起来看一条实际测试中很常见的链路。信息收集阶段通过短文件名枚举确认了后台入口和管理员目录。进入后台后发现有一个上传头像功能后缀名做了白名单校验但文件名没有重写。上传一张内容为脚本的图片改名为xxx.asp;.jpg直接访问时被IIS当作ASP执行脚本成功落地。接着用这个脚本读取Web目录下的conn.asp拿到数据库文件路径再直接请求这个路径把.mdb下载下来。这个例子里的所有环节都不是高难度操作但防守方只要断掉任何一环整条链就走不通。比如短文件名关闭了后台入口不会那么快暴露上传文件加了随机名解析漏洞就算存在也找不到一致的触发文件名.mdb不放Web目录连接文件被读到也下载不到数据库。6.3 事后复盘应该重点核对的事项防守方做完排查或者一次攻防演练结束后可以按这张清单逐项核对Windows补丁更新状态特别是历年IIS相关补丁。Web服务器版本和IIS配置是否还在使用存在解析缺陷的老模式。上传目录的脚本执行权限是否被显式关闭。上传文件的命名策略是否使用随机名和无扩展名方案。Access数据库文件的物理位置是否存放在Web根目录之外。连接文件里的数据库路径是否包含真实物理路径信息。访问日志里是否有批量通配符请求、异常Range头、未知.mdb下载记录。内网资产台账里是否还有无人认领的ASP遗留系统推动下线或纳入重点监控。其中最后一条最容易被忽略但往往最致命。很多企业把所有安全资源都投在新系统上老系统连个负责人都不明确出了问题都不知道找谁。资产盘点这步不做后面所有防御措施都是盲打。最后再啰嗦一句测试心得这些年测下来我最大的体会是攻击面从来都是组合出来的。单看一个短文件名漏洞危害不大单看一个Access注入点可能就是报错信息但把它们串起来就能形成一条通向核心数据的完整路径。这套思路在ASPAccess的老系统上适用在现代化的云原生架构里同样适用区别只是技术细节变了链路逻辑没变。另外遇到老技术栈不要带着轻慢的心态去测。老系统的高价值往往不在于技术难度而在于它承载的业务和数据真实存在。测试前把授权书确认清楚测试中控制好请求频率测试后把数据脱敏再写报告这些基本功比任何花哨的利用技巧都重要。守住这些规矩安全测试这条路才能走得长远。