我第一次在真实环境里看到web.config被人直接从浏览器下载下来是在一次例行的资产梳理里。一个跑着老版本 ASP.NET Web Forms 的内部站点发布时留下的备份文件没删干净地址栏敲进去整个配置文件就以纯文本形式铺在页面上。当时我盯着那份文件看了几秒才反应过来——真正值钱的不是里面那条数据库连接串而是machineKey节点里那两串长得像乱码的十六进制字符。machineKey一暴露ViewState 这道原本用来保证客户端提交的页面状态没被改过的闸门就形同虚设。攻击者可以自己签发一张合法的票据让服务端在回发时反序列化任意对象图最终落到代码执行。这条链路在 ASP.NET 体系里存在了很多年编号一直在变但底层逻辑几乎没变过。本文讨论的这个案例编号就是把配置文件泄露—密钥暴露—反序列化这三段串成一条完整链路的典型样本我会从原理、链路、检测、加固四个角度把它拆开讲透。做运维的、写后端的、做蓝队应急的只要手上有 Web Forms 资产这篇内容都值得对照着过一遍。1. 这个漏洞链路到底在讲什么1.1 把三个关键词串成一条完整的攻击路径很多人第一次看到这个标题会有点懵web.config、machineKey、ViewState这三个词看起来各说各的为什么能凑成一条漏洞链其实它们是一条流水线上的三个工位缺一不可。web.config是 ASP.NET 应用的配置文件相当于整个站点的说明书加钥匙串里面写着数据库怎么连、错误页怎么显示、会话怎么保持以及最关键的——machineKey用什么算法、用什么密钥。machineKey是这套体系里的签名章和保险柜钥匙负责对客户端提交上来的数据做完整性校验和加解密。ViewState则是 Web Forms 特有的机制把页面控件的状态序列化后塞进 HTML 的一个隐藏字段里发给浏览器用户点按钮回发时再原样带回来服务端反序列化还原页面状态。这三者的关系可以用一个很生活化的场景说明ViewState是一张写好了金额的提货单machineKey是盖在单子上的防伪章web.config是那本记录了章长什么样的登记簿。正常情况下你改单子上的金额章对不上仓库不认。但如果登记簿被人翻拍走了你完全可以自己刻一枚一模一样的章盖上之后仓库照单发货。整条链路的核心就在这个章的照片泄露上其余的都是工程实现细节。1.2 为什么配置文件泄露是这条链的起点配置文件泄露这件事在甲方做资产梳理的时候属于年年查、年年有的老问题但它很少被当成高危漏洞对待因为大部分人的直觉是里面最多有个数据库密码。这种直觉在十年前可能还成立现在明显不够用了。web.config被读出来的途径比想象中多得多。最常见的是发布残留运维图省事改配置前先复制一份web.config.bak或者web.config.20240315改完忘了删而 IIS 默认的静态文件处理并不会拦截这些后缀。其次是编辑器临时文件某些编辑器在保存时会生成带波浪号或者.swp后缀的副本同样躺在站点目录里。再就是目录配置失误把整个发布包含源码、含配置放进了可访问的静态目录或者某个子应用的虚拟目录指向了错误的位置。还有一种更隐蔽的情况应用在异常时把物理路径和配置片段打进了错误页攻击者顺着错误信息就能推断出目录结构再去碰运气找备份文件。这里有个容易被忽略的点web.config本身受 IIS 的requestFiltering保护直接请求通常返回 404 或者 403。但.bak、.old、.txt、.zip这些变体不在默认拦截名单里所以真正被下载走的往往是配置文件的副本而不是配置文件本身。我在做排查的时候习惯把站点目录下所有名字里带config的文件全部列一遍包括.config.bak、config.txt、web.config.orig、appsettings.json.bak现在不少项目是混合栈两套配置并存。1.3 谁需要认真读完这篇内容这篇内容的目标读者分三类。第一类是运维和系统管理员你们手上有 IIS 或者兼容 ASP.NET 的运行时环境需要知道哪些配置项是一旦泄露就等于失守的。第二类是后端开发尤其是维护老项目的同学很多 Web Forms 应用已经进入能跑就别动的状态但恰恰是这种状态最危险因为当年写代码的人已经不在没人记得machineKey是怎么配的。第三类是安全从业者和蓝队应急人员你们需要在流量和日志里识别这类攻击的痕迹也需要一套能落地的检测脚本。前置知识要求不高知道 HTTP 请求响应是怎么回事、大概了解什么是序列化就够了。涉及具体配置的地方我会把参数怎么算、为什么这么选讲清楚涉及代码的地方我只给防御侧的自检脚本不会给可直接用于攻击的成品。这一点先说明白本文的所有技术细节都服务于发现和阻断链路还原的目的是让你知道在哪一步设卡。2. ViewState 与 machineKey 的底层机制拆解2.1 ViewState 不是缓存是客户端可写的票据很多人对 ViewState 有个误解觉得它是服务端存在客户端的一份缓存是用来提升性能的。这个理解偏差会直接影响你对风险的判断。ViewState 的本质是一段完全由客户端持有、并且在回发时会被服务端信任并解析的数据它更像是浏览器替服务端保管的一张票据而不是缓存。具体流程是这样的页面渲染时ASP.NET 把页面上所有控件的状态文本框里填了什么、下拉框选了哪项、GridView 当前在第几页收集起来用ObjectStateFormatter或者更老的LosFormatter序列化成一串二进制再 Base64 编码塞进input typehidden name__VIEWSTATE。用户提交表单时这串东西原封不动回到服务端页面生命周期里的LoadPageStateFromPersistenceMedium会把它解码、反序列化还原成对象图然后各个控件从对象图里取回自己的状态。关键在于反序列化这三个字。反序列化不是简单地读一段 JSON它会根据数据流里携带的类型信息在运行时动态加载对应的类型、创建实例、调用反序列化回调。这意味着数据流里的类型名是攻击者可以影响的只要他能通过完整性校验。这就是为什么 ViewState 一旦失去 MAC 保护风险等级会直接从信息泄露跳到远程代码执行。2.2 machineKey 里的两个密钥各管什么machineKey节点通常长这样machineKey validationKey... decryptionKey... validationHMACSHA256 decryptionAES /四个属性里validationKey和decryptionKey是两把完全不同的钥匙管的也是两件不同的事很多文档把它们混在一起讲导致配置的时候容易搞错长度。validationKey负责完整性校验。服务端用它对 ViewState 的内容算一个 HMAC把结果附在数据末尾。回发时重新算一遍对不上就拒绝。它防的是篡改不防偷看。对应的validation属性决定用哪种 HMAC 算法可选值包括MD5、SHA1、HMACSHA256、HMACSHA384、HMACSHA512、AES、3DES。decryptionKey负责加密。只有当ViewStateEncryptionMode设为Always或者页面通过Page.RegisterRequiresViewStateEncryption()主动要求加密时才会用到。它防的是偷看让用户看不到 ViewState 里到底存了什么业务数据。对应的decryption属性可选Auto、AES、3DES、DES。这里有个非常重要的认知加密不能替代完整性校验。有些老项目为了安全把ViewStateEncryptionMode设成Always就以为万事大吉但如果没有 MAC攻击者完全可以构造一段用未知密钥加密的数据——服务端解不开但某些实现路径下会先尝试解密再校验或者干脆在校验缺失的情况下把解密失败的数据丢进反序列化流程。更直接的做法是只要enableViewStateMac被关掉根本不需要密钥就能构造票据加不加密都无所谓。2.3 算法强度与看起来安全的误区关于算法选择行业里有一堆似是而非的说法我挑几个常见的澄清一下。第一种说法是SHA1 已经被攻破了所以validationSHA1不安全。这个说法混淆了碰撞攻击和 HMAC 伪造。SHA1 的碰撞攻击确实早就实用了但 HMAC-SHA1 目前没有公开的、实际可行的伪造攻击。也就是说如果validationKey没泄露HMACSHA1作为完整性校验算法在可预见的未来仍然够用。当然新配置没必要再用 SHA1直接上HMACSHA256就行成本一样。第二种说法是密钥越长越安全我直接填 512 个十六进制字符。长度确实重要但更重要的是匹配。不同算法对密钥长度的要求不一样填错了要么被运行时截断要么直接抛异常。下面这张表是我实际配置时用的对照建议保存下来用途算法推荐密钥长度字节十六进制字符数validationKeyHMACSHA25632 至 6464 至 128validationKeyHMACSHA51264128validationKeySHA1旧配置64128decryptionKeyAES128 位1632decryptionKeyAES256 位3264decryptionKey3DES2448第三种说法是用AutoGenerate最省事让框架自己生成。这个在单机开发环境完全没问题但在生产环境尤其是多节点部署时是个坑。AutoGenerate生成的密钥默认存在机器的配置存储里每台机器各自不同一旦应用池回收或者机器重装密钥就变了所有在途的 ViewState 和 Forms 认证票据全部失效。更麻烦的是有些部署工具在迁移时会把自动生成的密钥固化写回到web.config里于是本来只在内存和注册表里的东西变成了磁盘上的明文——这就把密钥存在但难拿到变成了密钥就摆在文件里。2.4 默认配置下为什么容易出事从框架演进的视角看这个问题在不同版本上的严重程度差别很大。在比较老的版本里enableViewStateMac是可以被关闭的而且有些历史教程为了排查问题真的建议关掉它。一旦关掉ViewState 就是完全裸奔的状态攻击者不需要任何密钥直接构造恶意序列化数据就能打。这类站点在存量资产里仍然存在尤其是那些十几年没升级过的内部系统。从 .NET Framework 4.5.2 开始enableViewStateMac被强制为true配置文件里写false也会被忽略。这一步堵住了直接关 MAC的路但没堵住密钥泄露的路——只要machineKey拿到手MAC 依然可以被正确计算出来。所以很多人升级到 4.5.2 之后就觉得安全了这个判断是错的。补丁堵的是配置错误堵不住钥匙被偷。还有一个经常被忽略的默认行为customErrors在RemoteOnly或者Off状态下会把完整的异常堆栈返回给客户端。攻击者在构造 ViewState 的过程中如果类型名写错、格式不对服务端会抛出反序列化异常堆栈里往往包含运行时的版本号、程序集名称、页面类型全名。这些信息对攻击者是极好的向导能大幅缩短试错时间。所以关掉详细错误信息不只是体验问题它直接影响攻击成本。3. 从配置文件泄露到密钥还原3.1 配置文件被读出来的常见途径与检测方法前面提过真正泄露的往往是配置文件的副本所以在排查的时候光检查web.config本身能不能访问是不够的必须把变体一起查。我常用的检测思路是列一份常见变体清单然后对站点根目录和几个关键子目录逐个发请求看返回状态码和响应体的前若干字节。清单不用太长覆盖高频的就够了# 针对自有资产做配置泄露自查仅用于授权范围内的资产梳理 BASEhttps://your-site.example for name in web.config web.config.bak web.config.old web.config.orig \ web.config.save web.config.txt web.config.zip \ web.config.20240101 appsettings.json.bak; do code$(curl -s -o /tmp/resp.txt -w %{http_code} \ --max-time 5 $BASE/$name) size$(wc -c /tmp/resp.txt) echo $name - $code ($size bytes) done判定的关键不在状态码而在响应体内容。有些服务器会把 404 也返回 200前端路由接管所以要抓特征响应里是否出现configuration、system.web、machineKey、connectionString这类标签。只要出现任何一个就当泄露处理不要心存侥幸。除了文件名变体还有几类来源值得关注。一是版本控制残留目录比如站点目录下多了.git、.svn虽然里面不是web.config但能拉到完整的源码和配置模板。二是压缩包发布包没有从站点目录移走通过 URL 就能下载。三是日志目录应用的错误日志里可能打出了配置片段。四是第三方组件的默认路径一些老的管理后台组件会带自己的配置目录。这几类我都实际遇到过其中压缩包最容易被忽视因为它名字往往很普通比如publish.zip、site_2024.zip。3.2 配置文件里哪几个节点最致命拿到一份web.config不要从头读到尾直接按优先级看几个节点节点关键属性泄露后果machineKeyvalidationKey / decryptionKey / validation / decryption可伪造 ViewState 与认证票据直达反序列化system.web/authenticationforms 的 protection、name、path配合 machineKey 可伪造身份 CookieconnectionStringsconnectionString数据库直连横向移动appSettings各种 key第三方接口密钥、对象存储凭据system.web/httpRuntimerequestValidationMode、maxRequestLength判断能否提交大体积请求体system.webServer/securityrequestFiltering 配置判断是否还有其他后缀可下载system.web/customErrorsmode详细错误是否对外暴露system.web/pagesenableViewStateMac、viewStateEncryptionMode直接决定攻击门槛我按致命程度排了个序machineKey排第一没有悬念因为它同时影响 ViewState 和 Forms 认证两条路径。authentication节点排第二是因为它跟machineKey是联动的Forms 认证的 Cookie 也是用machineKey加密签名的拿到密钥之后不仅能打 ViewState还能直接伪造一个管理员身份的 Cookie连登录都省了。这一点在很多分析里被漏掉了。3.3 拿到密钥后的验证思路防御视角站在防御方我们需要回答一个具体问题假设配置文件已经泄露了攻击者能不能用这份密钥成功伪造一个通过校验的 ViewState这个问题的答案决定了应急响应的等级。验证方法不复杂核心是对现有页面的 ViewState 做一次重新签名并比对。下面这段 C# 只做校验不做任何数据构造可以在内部环境跑// 防御自检用配置文件中的 validationKey 重新计算 ViewState 的 HMAC // 目的仅是确认若密钥泄露签名是否可被复现 using System; using System.Security.Cryptography; using System.Text; public static class ViewStateMacCheck { public static bool VerifyMac(byte[] viewStateWithMac, string validationKeyHex, string algorithm, int macSizeBytes) { if (viewStateWithMac.Length macSizeBytes) return false; int dataLen viewStateWithMac.Length - macSizeBytes; byte[] data new byte[dataLen]; byte[] mac new byte[macSizeBytes]; Buffer.BlockCopy(viewStateWithMac, 0, data, 0, dataLen); Buffer.BlockCopy(viewStateWithMac, dataLen, mac, 0, macSizeBytes); byte[] key HexToBytes(validationKeyHex); using (var hmac CreateHmac(algorithm, key)) { byte[] computed hmac.ComputeHash(data); return CryptographicOperations.FixedTimeEquals(computed, mac); } } private static HMAC CreateHmac(string algorithm, byte[] key) { switch (algorithm.ToUpperInvariant()) { case HMACSHA256: return new HMACSHA256(key); case HMACSHA384: return new HMACSHA384(key); case HMACSHA512: return new HMACSHA512(key); case SHA1: return new HMACSHA1(key); default: throw new NotSupportedException(algorithm); } } private static byte[] HexToBytes(string hex) { byte[] bytes new byte[hex.Length / 2]; for (int i 0; i bytes.Length; i) bytes[i] Convert.ToByte(hex.Substring(i * 2, 2), 16); return bytes; } }如果这段代码对某个真实页面的 ViewState 返回true说明密钥确实匹配攻击者拿到同样的密钥之后也能算出正确的 MAC风险等级就是最高。如果返回false可能是密钥不匹配也可能是页面对 ViewState 做了额外处理比如分块、压缩需要进一步确认。macSizeBytes 的取值跟算法对应SHA1 是 20SHA256 是 32SHA384 是 48SHA512 是 64。注意这段代码只能在你自己拥有或已获授权的资产上运行。对非授权目标做任何形式的签名验证都属于越界行为。4. ViewState 反序列化的完整链路还原4.1 序列化格式解析从 Base64 到对象图要理解这条链路为什么能走到代码执行得先看清楚 ViewState 里到底装了什么。把__VIEWSTATE的值做一次 Base64 解码你会得到一段二进制。早期用LosFormatter序列化的数据开头通常能看到0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF这样的标记后面跟着一串类型标识 值的配对结构。较新版本用ObjectStateFormatter格式更紧凑用单字节的 token 表示类型后面紧跟值。不管哪种格式核心结构是一样的类型信息内嵌在数据流里。序列化的时候框架会把对象的类型全名含程序集信息写进去反序列化的时候运行时读到这个类型名就会去加载对应的程序集、创建实例、填充字段。这个过程是数据驱动类型加载而不是预先声明类型再解析数据。这个设计本身没错.NET 的很多序列化机制都这样。问题出在类型加载之后会触发什么。很多类在反序列化时会有副作用有的会在OnDeserialized回调里读写文件有的会在构造函数里初始化一个连接有的会在Equals或者GetHashCode被调用时执行一段逻辑。这些副作用单独看都是正常功能但被攻击者组合起来就能形成一条从数据到行为的路径。业界把这种被组合利用的类叫作 gadget把组合起来的路径叫作 gadget chain。4.2 类型混淆与 gadget 的落点具体到 ViewState 这个场景gadget 的落点大致分三类我按实际遇到过的频率排第一类是文件写入。某些类在反序列化时会根据字段值决定写入路径和内容如果字段可以被数据流控制就能往站点目录写一个可执行脚本或者配置文件。这类落点最直接也最容易被检测到因为文件系统会有痕迹。第二类是进程或命令启动。某些类在反序列化或者后续属性访问时会调用外部程序参数来自字段值。这类落点威力最大但也最依赖运行时的权限配置。应用池如果是以高权限账户跑的后果就非常严重如果按最小权限原则配置影响面会小很多这也是为什么应用池降权这条老生常谈的加固措施一直有效。第三类是反射调用。通过控制类型名和方法名让运行时加载任意类型并调用其方法。这类落点最灵活但也最脆弱因为强名称、程序集版本、运行时补丁都可能让链条失效。这里我要强调一点具体是哪个类、怎么串起来本文不会给。一方面这是武器化细节另一方面这类链条更新极快写死了很快就过时。作为防御方你需要记住的是存在这类落点这个事实以及MAC 校验是唯一可靠的拦截点这个结论。只要 MAC 有效且密钥没泄露任何 gadget 都进不来因为它们全都必须通过反序列化这一关而反序列化的前提是数据能通过校验。4.3 为什么说这是反序列化而不是注入这个区分不是咬文嚼字它直接影响你选什么防护手段。注入类漏洞SQL 注入、命令注入、LDAP 注入的本质是数据被当成了指令防护的核心是参数化和转义。反序列化漏洞的本质是数据流里携带了类型信息运行时按类型信息加载并执行代码防护的核心是确保数据来源可信——也就是完整性校验而不是过滤特殊字符。这个区别带来的实操差异很大。你没法通过过滤危险字符来防反序列化因为 Base64 编码后的数据流里可以有任意字节你要过滤什么你也没法通过限制请求体大小来防因为一个精简的 gadget 数据流可能只有几百字节。唯一有效的手段就是确保enableViewStateMac开启、machineKey高强度且不泄露、必要时开启 ViewState 加密减少信息暴露面。还有一点容易混淆__VIEWSTATEGENERATOR这个隐藏字段经常被误认为有安全作用。它的实际用途是标识这个 ViewState 属于哪个页面类型防止一个页面的 ViewState 被拿到另一个页面去用它参与校验的方式是基于页面类型的哈希而不是基于密钥的 HMAC。也就是说它是可以被重算的不构成安全边界。真正的安全边界是__VIEWSTATE末尾那段 MAC以及__EVENTVALIDATION字段——后者确实用machineKey签名防的是事件参数被伪造。4.4 一条链路的时间线还原与拦截点分布把整个链路按时间顺序拆开每一步都标注防御方可以在哪里设卡这样看起来最清楚阶段攻击者的动作防御拦截点资产发现探测站点指纹识别 ASP.NET Web Forms隐藏版本头、统一错误页配置探测尝试访问配置文件的各类变体requestFiltering 扩展名黑名单、清理发布残留密钥提取从泄露文件中读取 machineKey敏感文件权限、密钥托管分离算法识别判断 validation/decryption 算法与密钥长度无直接拦截属于信息面收敛问题票据构造按算法计算 MAC拼装序列化数据无拦截离线完成回发触发构造 POST 请求提交恶意 ViewStateWAF 规则、请求体特征检测反序列化服务端校验通过后加载类型MAC 校验失败即终止最后一道闸门落地执行gadget 触发文件写入或进程启动应用池最小权限、目录写入限制、EDR这张表里最值得注意的是票据构造和回发触发之间的分界。构造过程完全离线防御方看不到任何流量一旦开始回发就已经到了最后阶段。所以真正有效的防御窗口在前三行——不让配置文件泄露不给密钥提取的机会。等到流量侧看到异常基本已经是攻击者正在尝试而不是攻击者还在准备。反序列化这一步是最后的闸门。MAC 校验通过就意味着服务端认为这数据是自己签发的后面的类型加载就是合法行为。所以如果密钥已经泄露光靠应用层是拦不住的必须靠运行时防护最小权限、文件写入限制、行为监控来兜底。5. 检测与排查怎么判断自己的站点有没有中招5.1 资产自查的脚本化思路应急响应的第一步永远是摸清家底。我一般分两个维度做一是哪些站点可能泄露配置二是哪些站点的 machineKey 配置有问题。第一个维度用前面那个 curl 循环就够了重点是把结果结构化保存下来方便后面复查。第二个维度需要读配置文件可以写个 PowerShell 脚本批量扫 IIS 的站点目录# 批量检查 IIS 站点目录下 web.config 的 machineKey 配置 # 仅用于自有服务器的合规自查 $sitesRoot C:\inetpub Get-ChildItem -Path $sitesRoot -Recurse -Filter web.config -ErrorAction SilentlyContinue | ForEach-Object { $path $_.FullName try { [xml]$cfg Get-Content $path -Raw $mk $cfg.configuration.system.web.machineKey if ($null -eq $mk) { [PSCustomObject]{ Path$path; Status缺少machineKey节点; Validation-; Decryption- } } else { $vLen if ($mk.validationKey) { $mk.validationKey.Length } else { 0 } $dLen if ($mk.decryptionKey) { $mk.decryptionKey.Length } else { 0 } [PSCustomObject]{ Path $path Status if ($mk.validationKey -eq AutoGenerate) { AutoGenerate } else { 显式配置 } Validation $($mk.validation) ($vLen hex) Decryption $($mk.decryption) ($dLen hex) } } } catch { [PSCustomObject]{ Path$path; Status解析失败; Validation-; Decryption- } } } | Format-Table -AutoSize输出里重点看三种情况AutoGenerate的多节点部署下会出问题、validation是SHA1或MD5的不是漏洞但说明配置陈旧、密钥长度明显偏短的比如 32 个十六进制字符配HMACSHA256实际强度不足。5.2 日志与流量侧的可疑信号如果怀疑已经被打过日志是最直接的证据来源。IIS 日志里我重点看几类记录第一类是针对配置文件的请求。状态码 200 且 URL 以.config、.bak、.old、.zip结尾的全部标红。注意有些扫描器会带一堆变体后缀这类请求通常集中在很短时间内很好识别。第二类是异常的 POST 请求。正常用户的 POST 请求体大小在一个稳定区间内如果某个 IP 的 POST 请求体突然比正常值大好几倍而且请求的是同一个页面就要警惕——ViewState 变大的一个常见原因就是被塞了东西。第三类是同一 IP 的高频 POST。正常用户提交表单不会一秒好几次自动化工具的节奏感很明显。日志分析的命令示例假设是标准的 W3C 格式日志# 从 IIS 日志里筛出对配置类文件的成功请求 awk -F $9 200 $5 ~ /\.(config|bak|old|zip|orig)$/ {print $1, $4, $5, $7} \ u_ex*.log | sort | uniq -c | sort -rn | head -50 # 统计单位时间内 POST 请求体大小的异常分布 awk -F $5 POST {print $1, $8} u_ex*.log \ | awk {sum[$1]$2; cnt[$1]} END {for (i in sum) print i, sum[i]/cnt[i], cnt[i]} \ | sort -k2 -rn | head -20除了日志还要看文件系统。攻击成功后最常见的落地动作是往站点目录写文件所以检查bin、App_Data、上传目录、站点根目录下最近修改过的文件很有必要。重点关注后缀是.aspx、.ashx、.asmx、.config且创建时间集中在非发布时段的文件。另外 IIS 应用池账户对站点目录的写权限要单独审一遍很多站点为了方便上传直接给了Modify权限这等于给攻击者开了后门。5.3 一份可以直接照着做的自查清单把上面的内容整理成清单方便逐项打勾检查项检查方法判定标准配置文件是否可下载逐个尝试变体后缀并检查响应体响应体含配置标签即判泄露machineKey 是否 AutoGenerate读配置文件或脚本扫描生产环境出现即需处理validation 算法是否为老算法读配置SHA1/MD5 建议升级密钥长度是否达标数十六进制字符数对照第 2.3 节表格enableViewStateMac 是否关闭读pages节点出现 false 立即整改应用池账户权限查看站点目录 ACL非必要不授予写权限详细错误是否外泄访问一个不存在的路径看响应出现堆栈即需关闭站点目录是否有备份文件文件系统扫描存在即清理是否有异常落地文件按修改时间排序非发布时段新增文件需核实日志中是否有配置探测按后缀过滤大量命中即视为已探测这张表我在几次应急里都用过实际耗时大概半小时到一小时取决于站点数量。建议做成定期任务每月跑一次比出了事再查要省心得多。6. 加固与修复把这条链路从中间掐断6.1 应急状态下先做的三件事如果确认配置已经泄露不要犹豫按这个顺序来第一步立刻把泄露的文件从站点目录移走或者改名为不可访问的状态同时检查同目录下是否还有其他备份。这一步是止血虽然不能挽回已经发生的泄露但能防止持续暴露。第二步轮换machineKey。这是最关键的一步因为只要密钥还是老的攻击者手上的工具就依然有效。轮换的方式后面详细讲。轮换的同时把 Forms 认证的decryptionKey一起换掉其实它用的就是同一个machineKey这样所有已签发的认证 Cookie 全部失效攻击者没法拿着伪造的 Cookie 继续访问。第三步排查落地痕迹。按第 5.2 节的方法查文件系统和日志重点看泄露发生之后到轮换之前的这段时间窗口内有没有可疑的文件写入、进程创建、异常登录。这一步决定要不要升级为完整的事件响应。顺序不能反。有些团队习惯先排查再处置结果排查过程中攻击者一直在利用泄露的密钥等于边救火边浇油。6.2 machineKey 的正确生成与轮换姿势生成高强度密钥不要用脑补的字符串也不要用在线生成器谁知道它有没有留底。本机生成最稳妥# 生成 64 字节128 个十六进制字符的 validationKey function New-HexKey([int]$byteLength) { $bytes New-Object byte[] $byteLength [System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes) ($bytes | ForEach-Object { $_.ToString(X2) }) -join } $validationKey New-HexKey 64 # 对应 HMACSHA256/HMACSHA512 $decryptionKey New-HexKey 32 # 对应 AES-256 Write-Host validationKey$validationKey Write-Host decryptionKey$decryptionKey拿到两串字符后写进配置system.web machineKey validationKey上一步生成的128位字符 decryptionKey上一步生成的64位字符 validationHMACSHA256 decryptionAES / pages enableViewStateMactrue viewStateEncryptionModeAuto / customErrors modeOn defaultRedirect/error.html / /system.web轮换的时候有几个坑必须提前想到。第一所有节点必须同步换负载均衡后面挂几台机器密钥就必须完全一致否则请求打到不同节点会随机失败。第二会话会全部失效用户需要重新登录如果是在业务高峰期做要提前通知。第三有些加密字段会解不开如果业务代码里用machineKey加密了持久化数据比如存在数据库里的敏感字段换密钥之后这些数据就废了这种情况必须先做数据迁移或者保留旧密钥做兼容解密。第四改动需要重启应用池配置节的变更不会热生效。注意轮换前一定要在测试环境验证一遍完整流程尤其是涉及多节点和持久化加密数据的场景。我见过不止一次因为漏掉某个节点导致线上随机 500 的事故。6.3 配置文件访问控制的层层设防密钥轮换是治标防止泄露是治本。IIS 层面有几层配置可以做建议全部开启system.webServer security requestFiltering !-- 禁止访问配置文件及其常见变体 -- fileExtensions add fileExtension.config allowedfalse / add fileExtension.bak allowedfalse / add fileExtension.old allowedfalse / add fileExtension.orig allowedfalse / add fileExtension.zip allowedfalse / /fileExtensions hiddenSegments add segmentApp_Data / add segment.git / add segment.svn / /hiddenSegments /requestFiltering /security /system.webServer这里要注意fileExtensions的allowedfalse是全局生效的如果你的站点确实需要对外提供.zip下载比如导出功能要单独给对应目录开白名单而不是整体放开。除了 IIS 配置部署流程也要改。发布脚本里加一步清理残留文件把*.bak、*.old、*.zip、*.log全部删掉再上线。这一步看似琐碎但能挡掉大部分低级泄露。另外建议把配置文件和站点目录物理分离配置文件放在站点目录之外通过配置节引用或者环境变量注入这样即使目录被遍历也拿不到配置。6.4 纵深防御从请求层到运行时的兜底MAC 校验是核心但不能只靠它。我的建议是至少铺三层第一层是请求层。WAF 上加规则拦截 URL 里带.config、.bak等后缀的请求对 POST 请求体大小设阈值超过阈值的直接拒绝或者挑战验证对短时间内同一 IP 的高频 POST 做限速。这些规则会误伤正常业务吗一般不会正常的表单提交不会触发这些特征。第二层是应用层。除了enableViewStateMac还可以考虑把不需要 ViewState 的页面直接关掉EnableViewStatefalse减少攻击面。对于纯展示型页面ViewState 本来就是浪费带宽。另外把customErrors设为On统一错误页不给攻击者任何堆栈信息。第三层是运行时。应用池账户降权是性价比最高的一条让IIS_IUSRS只有读和执行权限没有写权限上传目录单独开一个受限目录并禁止执行脚本。这样即使 gadget 链触发攻击者也写不进可执行文件最多往上传目录丢个文本。再配合文件完整性监控站点目录一旦有非预期变更就告警响应速度会快很多。7. 踩坑记录与常见问题速查7.1 换完密钥之后的一连串连锁反应密钥轮换这件事说起来就两行配置做起来能踩出一串坑。我把自己和同行踩过的整理一下。最典型的是 Forms 认证集体掉线。machineKey同时用于 Forms 认证票据的加密和签名换了密钥所有已签发的 Cookie 全部失效用户下次请求就被踢回登录页。如果站点有记住我功能用户会发现明明勾了记住我第二天来又要重新登录。这个不是 bug是预期行为但必须在变更窗口内提前通知最好选在低峰期做。第二个坑是分布式缓存里的会话数据。如果用了基于machineKey加密的会话状态比如 StateServer 或者自定义的加密 Cookie换密钥之后旧数据解不开表现为随机的解密异常。处理方式是清空会话存储让用户重新建立会话。第三个坑是加密的持久化字段。有些业务会把敏感信息用machineKey加密后存进数据库比如用户的身份证号、银行卡号。换密钥之后这些字段全部解不开读出来是乱码或者直接抛异常。这种情况必须在换密钥之前先做一次全量解密重加密或者保留旧密钥做双密钥兼容。我在一个项目里就遇到过因为漏了一个表上线后那块功能直接不可用回滚折腾了两个小时。第四个坑是节点不同步。负载均衡后面三台机器只改了两台剩下一台还在用旧密钥。表现是用户刷新几次就掉线一次日志里全是 MAC 校验失败。这个问题的排查成本很高因为现象是随机的容易误判成网络问题。7.2 多节点与 Web Garden 下的密钥一致性单机部署的密钥管理很简单写死在web.config里就行。多节点就麻烦了必须保证所有节点用完全相同的密钥否则前面说的随机失败就会出现。常见的做法有三种。第一种是把machineKey写在每台机器的web.config里靠配置管理工具比如配置中心或者自动化部署脚本保证一致。这种方式简单直接缺点是密钥散落在每台机器上任何一台被攻破都会导致全部失守。第二种是把machineKey放在共享配置里所有节点通过网络路径读取。这种方式一致性好但引入了单点依赖共享路径不可用的时候所有站点都起不来。第三种是用密钥托管服务启动时拉取密钥注入到配置里。这种方式安全性最好但改造成本高老项目一般不愿意动。我的建议是按资产重要性分级核心系统上密钥托管一般系统用配置中心统一下发边缘系统写死但要做好文件权限。不管用哪种都要建立一个密钥变更流程包括变更前的影响评估、变更中的灰度验证、变更后的回滚预案。还有一个容易被忽视的点Web Garden 模式同一个应用池开多个工作进程。这种模式下每个工作进程的内存里都有一份密钥缓存如果密钥是AutoGenerate不同进程生成的密钥可能不一样导致同一个用户在不同进程间切换时校验失败。所以只要开了 Web GardenmachineKey就必须显式配置。7.3 常见问题速查表现象可能原因处理方式用户随机掉登录多节点密钥不一致统一所有节点的 machineKey页面报 MAC 校验失败密钥变更未同步或 ViewState 被改检查节点配置一致性排查代理篡改换密钥后加密字段乱码持久化数据用旧密钥加密迁移数据或保留旧密钥做兼容解密应用池启动即报错密钥长度与算法不匹配对照第 2.3 节表格重新生成上传功能突然不可用requestFiltering 拦截了 .zip给上传目录单独开白名单站点目录出现陌生 .aspx已被利用落地立即隔离主机走完整应急流程日志里大量 config 探测已被扫描确认无泄露加固过滤规则AutoGenerate 下重启失效密钥随进程变化改为显式配置并纳入配置管理最后分享一个我自己养成的习惯每次做这类漏洞复盘我都会在文章或者笔记的最后留一行这个结论在什么条件下会失效。比如MAC 校验能拦住反序列化这个结论失效条件就是密钥泄露和enableViewStateMac 被关闭而后者在新版本里已经被强制前者才是真正的软肋。把失效条件写清楚比记住结论本身更有用因为下次遇到类似场景你会先去看那些条件成不成立而不是套用上次的答案。这条链路的本质从来不是某个具体的技术细节而是信任边界被打破之后下游所有校验都会失效——密钥是信任的根根一旦暴露上面盖多高的楼都没意义。 
长河君 · 2026/11/4 3:45:46 · 阅读 1.2k web.config泄露与machineKey/ViewState反序列化链路
我第一次在真实环境里看到web.config被人直接从浏览器下载下来是在一次例行的资产梳理里。一个跑着老版本 ASP.NET Web Forms 的内部站点发布时留下的备份文件没删干净地址栏敲进去整个配置文件就以纯文本形式铺在页面上。当时我盯着那份文件看了几秒才反应过来——真正值钱的不是里面那条数据库连接串而是machineKey节点里那两串长得像乱码的十六进制字符。machineKey一暴露ViewState 这道原本用来保证客户端提交的页面状态没被改过的闸门就形同虚设。攻击者可以自己签发一张合法的票据让服务端在回发时反序列化任意对象图最终落到代码执行。这条链路在 ASP.NET 体系里存在了很多年编号一直在变但底层逻辑几乎没变过。本文讨论的这个案例编号就是把配置文件泄露—密钥暴露—反序列化这三段串成一条完整链路的典型样本我会从原理、链路、检测、加固四个角度把它拆开讲透。做运维的、写后端的、做蓝队应急的只要手上有 Web Forms 资产这篇内容都值得对照着过一遍。1. 这个漏洞链路到底在讲什么1.1 把三个关键词串成一条完整的攻击路径很多人第一次看到这个标题会有点懵web.config、machineKey、ViewState这三个词看起来各说各的为什么能凑成一条漏洞链其实它们是一条流水线上的三个工位缺一不可。web.config是 ASP.NET 应用的配置文件相当于整个站点的说明书加钥匙串里面写着数据库怎么连、错误页怎么显示、会话怎么保持以及最关键的——machineKey用什么算法、用什么密钥。machineKey是这套体系里的签名章和保险柜钥匙负责对客户端提交上来的数据做完整性校验和加解密。ViewState则是 Web Forms 特有的机制把页面控件的状态序列化后塞进 HTML 的一个隐藏字段里发给浏览器用户点按钮回发时再原样带回来服务端反序列化还原页面状态。这三者的关系可以用一个很生活化的场景说明ViewState是一张写好了金额的提货单machineKey是盖在单子上的防伪章web.config是那本记录了章长什么样的登记簿。正常情况下你改单子上的金额章对不上仓库不认。但如果登记簿被人翻拍走了你完全可以自己刻一枚一模一样的章盖上之后仓库照单发货。整条链路的核心就在这个章的照片泄露上其余的都是工程实现细节。1.2 为什么配置文件泄露是这条链的起点配置文件泄露这件事在甲方做资产梳理的时候属于年年查、年年有的老问题但它很少被当成高危漏洞对待因为大部分人的直觉是里面最多有个数据库密码。这种直觉在十年前可能还成立现在明显不够用了。web.config被读出来的途径比想象中多得多。最常见的是发布残留运维图省事改配置前先复制一份web.config.bak或者web.config.20240315改完忘了删而 IIS 默认的静态文件处理并不会拦截这些后缀。其次是编辑器临时文件某些编辑器在保存时会生成带波浪号或者.swp后缀的副本同样躺在站点目录里。再就是目录配置失误把整个发布包含源码、含配置放进了可访问的静态目录或者某个子应用的虚拟目录指向了错误的位置。还有一种更隐蔽的情况应用在异常时把物理路径和配置片段打进了错误页攻击者顺着错误信息就能推断出目录结构再去碰运气找备份文件。这里有个容易被忽略的点web.config本身受 IIS 的requestFiltering保护直接请求通常返回 404 或者 403。但.bak、.old、.txt、.zip这些变体不在默认拦截名单里所以真正被下载走的往往是配置文件的副本而不是配置文件本身。我在做排查的时候习惯把站点目录下所有名字里带config的文件全部列一遍包括.config.bak、config.txt、web.config.orig、appsettings.json.bak现在不少项目是混合栈两套配置并存。1.3 谁需要认真读完这篇内容这篇内容的目标读者分三类。第一类是运维和系统管理员你们手上有 IIS 或者兼容 ASP.NET 的运行时环境需要知道哪些配置项是一旦泄露就等于失守的。第二类是后端开发尤其是维护老项目的同学很多 Web Forms 应用已经进入能跑就别动的状态但恰恰是这种状态最危险因为当年写代码的人已经不在没人记得machineKey是怎么配的。第三类是安全从业者和蓝队应急人员你们需要在流量和日志里识别这类攻击的痕迹也需要一套能落地的检测脚本。前置知识要求不高知道 HTTP 请求响应是怎么回事、大概了解什么是序列化就够了。涉及具体配置的地方我会把参数怎么算、为什么这么选讲清楚涉及代码的地方我只给防御侧的自检脚本不会给可直接用于攻击的成品。这一点先说明白本文的所有技术细节都服务于发现和阻断链路还原的目的是让你知道在哪一步设卡。2. ViewState 与 machineKey 的底层机制拆解2.1 ViewState 不是缓存是客户端可写的票据很多人对 ViewState 有个误解觉得它是服务端存在客户端的一份缓存是用来提升性能的。这个理解偏差会直接影响你对风险的判断。ViewState 的本质是一段完全由客户端持有、并且在回发时会被服务端信任并解析的数据它更像是浏览器替服务端保管的一张票据而不是缓存。具体流程是这样的页面渲染时ASP.NET 把页面上所有控件的状态文本框里填了什么、下拉框选了哪项、GridView 当前在第几页收集起来用ObjectStateFormatter或者更老的LosFormatter序列化成一串二进制再 Base64 编码塞进input typehidden name__VIEWSTATE。用户提交表单时这串东西原封不动回到服务端页面生命周期里的LoadPageStateFromPersistenceMedium会把它解码、反序列化还原成对象图然后各个控件从对象图里取回自己的状态。关键在于反序列化这三个字。反序列化不是简单地读一段 JSON它会根据数据流里携带的类型信息在运行时动态加载对应的类型、创建实例、调用反序列化回调。这意味着数据流里的类型名是攻击者可以影响的只要他能通过完整性校验。这就是为什么 ViewState 一旦失去 MAC 保护风险等级会直接从信息泄露跳到远程代码执行。2.2 machineKey 里的两个密钥各管什么machineKey节点通常长这样machineKey validationKey... decryptionKey... validationHMACSHA256 decryptionAES /四个属性里validationKey和decryptionKey是两把完全不同的钥匙管的也是两件不同的事很多文档把它们混在一起讲导致配置的时候容易搞错长度。validationKey负责完整性校验。服务端用它对 ViewState 的内容算一个 HMAC把结果附在数据末尾。回发时重新算一遍对不上就拒绝。它防的是篡改不防偷看。对应的validation属性决定用哪种 HMAC 算法可选值包括MD5、SHA1、HMACSHA256、HMACSHA384、HMACSHA512、AES、3DES。decryptionKey负责加密。只有当ViewStateEncryptionMode设为Always或者页面通过Page.RegisterRequiresViewStateEncryption()主动要求加密时才会用到。它防的是偷看让用户看不到 ViewState 里到底存了什么业务数据。对应的decryption属性可选Auto、AES、3DES、DES。这里有个非常重要的认知加密不能替代完整性校验。有些老项目为了安全把ViewStateEncryptionMode设成Always就以为万事大吉但如果没有 MAC攻击者完全可以构造一段用未知密钥加密的数据——服务端解不开但某些实现路径下会先尝试解密再校验或者干脆在校验缺失的情况下把解密失败的数据丢进反序列化流程。更直接的做法是只要enableViewStateMac被关掉根本不需要密钥就能构造票据加不加密都无所谓。2.3 算法强度与看起来安全的误区关于算法选择行业里有一堆似是而非的说法我挑几个常见的澄清一下。第一种说法是SHA1 已经被攻破了所以validationSHA1不安全。这个说法混淆了碰撞攻击和 HMAC 伪造。SHA1 的碰撞攻击确实早就实用了但 HMAC-SHA1 目前没有公开的、实际可行的伪造攻击。也就是说如果validationKey没泄露HMACSHA1作为完整性校验算法在可预见的未来仍然够用。当然新配置没必要再用 SHA1直接上HMACSHA256就行成本一样。第二种说法是密钥越长越安全我直接填 512 个十六进制字符。长度确实重要但更重要的是匹配。不同算法对密钥长度的要求不一样填错了要么被运行时截断要么直接抛异常。下面这张表是我实际配置时用的对照建议保存下来用途算法推荐密钥长度字节十六进制字符数validationKeyHMACSHA25632 至 6464 至 128validationKeyHMACSHA51264128validationKeySHA1旧配置64128decryptionKeyAES128 位1632decryptionKeyAES256 位3264decryptionKey3DES2448第三种说法是用AutoGenerate最省事让框架自己生成。这个在单机开发环境完全没问题但在生产环境尤其是多节点部署时是个坑。AutoGenerate生成的密钥默认存在机器的配置存储里每台机器各自不同一旦应用池回收或者机器重装密钥就变了所有在途的 ViewState 和 Forms 认证票据全部失效。更麻烦的是有些部署工具在迁移时会把自动生成的密钥固化写回到web.config里于是本来只在内存和注册表里的东西变成了磁盘上的明文——这就把密钥存在但难拿到变成了密钥就摆在文件里。2.4 默认配置下为什么容易出事从框架演进的视角看这个问题在不同版本上的严重程度差别很大。在比较老的版本里enableViewStateMac是可以被关闭的而且有些历史教程为了排查问题真的建议关掉它。一旦关掉ViewState 就是完全裸奔的状态攻击者不需要任何密钥直接构造恶意序列化数据就能打。这类站点在存量资产里仍然存在尤其是那些十几年没升级过的内部系统。从 .NET Framework 4.5.2 开始enableViewStateMac被强制为true配置文件里写false也会被忽略。这一步堵住了直接关 MAC的路但没堵住密钥泄露的路——只要machineKey拿到手MAC 依然可以被正确计算出来。所以很多人升级到 4.5.2 之后就觉得安全了这个判断是错的。补丁堵的是配置错误堵不住钥匙被偷。还有一个经常被忽略的默认行为customErrors在RemoteOnly或者Off状态下会把完整的异常堆栈返回给客户端。攻击者在构造 ViewState 的过程中如果类型名写错、格式不对服务端会抛出反序列化异常堆栈里往往包含运行时的版本号、程序集名称、页面类型全名。这些信息对攻击者是极好的向导能大幅缩短试错时间。所以关掉详细错误信息不只是体验问题它直接影响攻击成本。3. 从配置文件泄露到密钥还原3.1 配置文件被读出来的常见途径与检测方法前面提过真正泄露的往往是配置文件的副本所以在排查的时候光检查web.config本身能不能访问是不够的必须把变体一起查。我常用的检测思路是列一份常见变体清单然后对站点根目录和几个关键子目录逐个发请求看返回状态码和响应体的前若干字节。清单不用太长覆盖高频的就够了# 针对自有资产做配置泄露自查仅用于授权范围内的资产梳理 BASEhttps://your-site.example for name in web.config web.config.bak web.config.old web.config.orig \ web.config.save web.config.txt web.config.zip \ web.config.20240101 appsettings.json.bak; do code$(curl -s -o /tmp/resp.txt -w %{http_code} \ --max-time 5 $BASE/$name) size$(wc -c /tmp/resp.txt) echo $name - $code ($size bytes) done判定的关键不在状态码而在响应体内容。有些服务器会把 404 也返回 200前端路由接管所以要抓特征响应里是否出现configuration、system.web、machineKey、connectionString这类标签。只要出现任何一个就当泄露处理不要心存侥幸。除了文件名变体还有几类来源值得关注。一是版本控制残留目录比如站点目录下多了.git、.svn虽然里面不是web.config但能拉到完整的源码和配置模板。二是压缩包发布包没有从站点目录移走通过 URL 就能下载。三是日志目录应用的错误日志里可能打出了配置片段。四是第三方组件的默认路径一些老的管理后台组件会带自己的配置目录。这几类我都实际遇到过其中压缩包最容易被忽视因为它名字往往很普通比如publish.zip、site_2024.zip。3.2 配置文件里哪几个节点最致命拿到一份web.config不要从头读到尾直接按优先级看几个节点节点关键属性泄露后果machineKeyvalidationKey / decryptionKey / validation / decryption可伪造 ViewState 与认证票据直达反序列化system.web/authenticationforms 的 protection、name、path配合 machineKey 可伪造身份 CookieconnectionStringsconnectionString数据库直连横向移动appSettings各种 key第三方接口密钥、对象存储凭据system.web/httpRuntimerequestValidationMode、maxRequestLength判断能否提交大体积请求体system.webServer/securityrequestFiltering 配置判断是否还有其他后缀可下载system.web/customErrorsmode详细错误是否对外暴露system.web/pagesenableViewStateMac、viewStateEncryptionMode直接决定攻击门槛我按致命程度排了个序machineKey排第一没有悬念因为它同时影响 ViewState 和 Forms 认证两条路径。authentication节点排第二是因为它跟machineKey是联动的Forms 认证的 Cookie 也是用machineKey加密签名的拿到密钥之后不仅能打 ViewState还能直接伪造一个管理员身份的 Cookie连登录都省了。这一点在很多分析里被漏掉了。3.3 拿到密钥后的验证思路防御视角站在防御方我们需要回答一个具体问题假设配置文件已经泄露了攻击者能不能用这份密钥成功伪造一个通过校验的 ViewState这个问题的答案决定了应急响应的等级。验证方法不复杂核心是对现有页面的 ViewState 做一次重新签名并比对。下面这段 C# 只做校验不做任何数据构造可以在内部环境跑// 防御自检用配置文件中的 validationKey 重新计算 ViewState 的 HMAC // 目的仅是确认若密钥泄露签名是否可被复现 using System; using System.Security.Cryptography; using System.Text; public static class ViewStateMacCheck { public static bool VerifyMac(byte[] viewStateWithMac, string validationKeyHex, string algorithm, int macSizeBytes) { if (viewStateWithMac.Length macSizeBytes) return false; int dataLen viewStateWithMac.Length - macSizeBytes; byte[] data new byte[dataLen]; byte[] mac new byte[macSizeBytes]; Buffer.BlockCopy(viewStateWithMac, 0, data, 0, dataLen); Buffer.BlockCopy(viewStateWithMac, dataLen, mac, 0, macSizeBytes); byte[] key HexToBytes(validationKeyHex); using (var hmac CreateHmac(algorithm, key)) { byte[] computed hmac.ComputeHash(data); return CryptographicOperations.FixedTimeEquals(computed, mac); } } private static HMAC CreateHmac(string algorithm, byte[] key) { switch (algorithm.ToUpperInvariant()) { case HMACSHA256: return new HMACSHA256(key); case HMACSHA384: return new HMACSHA384(key); case HMACSHA512: return new HMACSHA512(key); case SHA1: return new HMACSHA1(key); default: throw new NotSupportedException(algorithm); } } private static byte[] HexToBytes(string hex) { byte[] bytes new byte[hex.Length / 2]; for (int i 0; i bytes.Length; i) bytes[i] Convert.ToByte(hex.Substring(i * 2, 2), 16); return bytes; } }如果这段代码对某个真实页面的 ViewState 返回true说明密钥确实匹配攻击者拿到同样的密钥之后也能算出正确的 MAC风险等级就是最高。如果返回false可能是密钥不匹配也可能是页面对 ViewState 做了额外处理比如分块、压缩需要进一步确认。macSizeBytes 的取值跟算法对应SHA1 是 20SHA256 是 32SHA384 是 48SHA512 是 64。注意这段代码只能在你自己拥有或已获授权的资产上运行。对非授权目标做任何形式的签名验证都属于越界行为。4. ViewState 反序列化的完整链路还原4.1 序列化格式解析从 Base64 到对象图要理解这条链路为什么能走到代码执行得先看清楚 ViewState 里到底装了什么。把__VIEWSTATE的值做一次 Base64 解码你会得到一段二进制。早期用LosFormatter序列化的数据开头通常能看到0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF这样的标记后面跟着一串类型标识 值的配对结构。较新版本用ObjectStateFormatter格式更紧凑用单字节的 token 表示类型后面紧跟值。不管哪种格式核心结构是一样的类型信息内嵌在数据流里。序列化的时候框架会把对象的类型全名含程序集信息写进去反序列化的时候运行时读到这个类型名就会去加载对应的程序集、创建实例、填充字段。这个过程是数据驱动类型加载而不是预先声明类型再解析数据。这个设计本身没错.NET 的很多序列化机制都这样。问题出在类型加载之后会触发什么。很多类在反序列化时会有副作用有的会在OnDeserialized回调里读写文件有的会在构造函数里初始化一个连接有的会在Equals或者GetHashCode被调用时执行一段逻辑。这些副作用单独看都是正常功能但被攻击者组合起来就能形成一条从数据到行为的路径。业界把这种被组合利用的类叫作 gadget把组合起来的路径叫作 gadget chain。4.2 类型混淆与 gadget 的落点具体到 ViewState 这个场景gadget 的落点大致分三类我按实际遇到过的频率排第一类是文件写入。某些类在反序列化时会根据字段值决定写入路径和内容如果字段可以被数据流控制就能往站点目录写一个可执行脚本或者配置文件。这类落点最直接也最容易被检测到因为文件系统会有痕迹。第二类是进程或命令启动。某些类在反序列化或者后续属性访问时会调用外部程序参数来自字段值。这类落点威力最大但也最依赖运行时的权限配置。应用池如果是以高权限账户跑的后果就非常严重如果按最小权限原则配置影响面会小很多这也是为什么应用池降权这条老生常谈的加固措施一直有效。第三类是反射调用。通过控制类型名和方法名让运行时加载任意类型并调用其方法。这类落点最灵活但也最脆弱因为强名称、程序集版本、运行时补丁都可能让链条失效。这里我要强调一点具体是哪个类、怎么串起来本文不会给。一方面这是武器化细节另一方面这类链条更新极快写死了很快就过时。作为防御方你需要记住的是存在这类落点这个事实以及MAC 校验是唯一可靠的拦截点这个结论。只要 MAC 有效且密钥没泄露任何 gadget 都进不来因为它们全都必须通过反序列化这一关而反序列化的前提是数据能通过校验。4.3 为什么说这是反序列化而不是注入这个区分不是咬文嚼字它直接影响你选什么防护手段。注入类漏洞SQL 注入、命令注入、LDAP 注入的本质是数据被当成了指令防护的核心是参数化和转义。反序列化漏洞的本质是数据流里携带了类型信息运行时按类型信息加载并执行代码防护的核心是确保数据来源可信——也就是完整性校验而不是过滤特殊字符。这个区别带来的实操差异很大。你没法通过过滤危险字符来防反序列化因为 Base64 编码后的数据流里可以有任意字节你要过滤什么你也没法通过限制请求体大小来防因为一个精简的 gadget 数据流可能只有几百字节。唯一有效的手段就是确保enableViewStateMac开启、machineKey高强度且不泄露、必要时开启 ViewState 加密减少信息暴露面。还有一点容易混淆__VIEWSTATEGENERATOR这个隐藏字段经常被误认为有安全作用。它的实际用途是标识这个 ViewState 属于哪个页面类型防止一个页面的 ViewState 被拿到另一个页面去用它参与校验的方式是基于页面类型的哈希而不是基于密钥的 HMAC。也就是说它是可以被重算的不构成安全边界。真正的安全边界是__VIEWSTATE末尾那段 MAC以及__EVENTVALIDATION字段——后者确实用machineKey签名防的是事件参数被伪造。4.4 一条链路的时间线还原与拦截点分布把整个链路按时间顺序拆开每一步都标注防御方可以在哪里设卡这样看起来最清楚阶段攻击者的动作防御拦截点资产发现探测站点指纹识别 ASP.NET Web Forms隐藏版本头、统一错误页配置探测尝试访问配置文件的各类变体requestFiltering 扩展名黑名单、清理发布残留密钥提取从泄露文件中读取 machineKey敏感文件权限、密钥托管分离算法识别判断 validation/decryption 算法与密钥长度无直接拦截属于信息面收敛问题票据构造按算法计算 MAC拼装序列化数据无拦截离线完成回发触发构造 POST 请求提交恶意 ViewStateWAF 规则、请求体特征检测反序列化服务端校验通过后加载类型MAC 校验失败即终止最后一道闸门落地执行gadget 触发文件写入或进程启动应用池最小权限、目录写入限制、EDR这张表里最值得注意的是票据构造和回发触发之间的分界。构造过程完全离线防御方看不到任何流量一旦开始回发就已经到了最后阶段。所以真正有效的防御窗口在前三行——不让配置文件泄露不给密钥提取的机会。等到流量侧看到异常基本已经是攻击者正在尝试而不是攻击者还在准备。反序列化这一步是最后的闸门。MAC 校验通过就意味着服务端认为这数据是自己签发的后面的类型加载就是合法行为。所以如果密钥已经泄露光靠应用层是拦不住的必须靠运行时防护最小权限、文件写入限制、行为监控来兜底。5. 检测与排查怎么判断自己的站点有没有中招5.1 资产自查的脚本化思路应急响应的第一步永远是摸清家底。我一般分两个维度做一是哪些站点可能泄露配置二是哪些站点的 machineKey 配置有问题。第一个维度用前面那个 curl 循环就够了重点是把结果结构化保存下来方便后面复查。第二个维度需要读配置文件可以写个 PowerShell 脚本批量扫 IIS 的站点目录# 批量检查 IIS 站点目录下 web.config 的 machineKey 配置 # 仅用于自有服务器的合规自查 $sitesRoot C:\inetpub Get-ChildItem -Path $sitesRoot -Recurse -Filter web.config -ErrorAction SilentlyContinue | ForEach-Object { $path $_.FullName try { [xml]$cfg Get-Content $path -Raw $mk $cfg.configuration.system.web.machineKey if ($null -eq $mk) { [PSCustomObject]{ Path$path; Status缺少machineKey节点; Validation-; Decryption- } } else { $vLen if ($mk.validationKey) { $mk.validationKey.Length } else { 0 } $dLen if ($mk.decryptionKey) { $mk.decryptionKey.Length } else { 0 } [PSCustomObject]{ Path $path Status if ($mk.validationKey -eq AutoGenerate) { AutoGenerate } else { 显式配置 } Validation $($mk.validation) ($vLen hex) Decryption $($mk.decryption) ($dLen hex) } } } catch { [PSCustomObject]{ Path$path; Status解析失败; Validation-; Decryption- } } } | Format-Table -AutoSize输出里重点看三种情况AutoGenerate的多节点部署下会出问题、validation是SHA1或MD5的不是漏洞但说明配置陈旧、密钥长度明显偏短的比如 32 个十六进制字符配HMACSHA256实际强度不足。5.2 日志与流量侧的可疑信号如果怀疑已经被打过日志是最直接的证据来源。IIS 日志里我重点看几类记录第一类是针对配置文件的请求。状态码 200 且 URL 以.config、.bak、.old、.zip结尾的全部标红。注意有些扫描器会带一堆变体后缀这类请求通常集中在很短时间内很好识别。第二类是异常的 POST 请求。正常用户的 POST 请求体大小在一个稳定区间内如果某个 IP 的 POST 请求体突然比正常值大好几倍而且请求的是同一个页面就要警惕——ViewState 变大的一个常见原因就是被塞了东西。第三类是同一 IP 的高频 POST。正常用户提交表单不会一秒好几次自动化工具的节奏感很明显。日志分析的命令示例假设是标准的 W3C 格式日志# 从 IIS 日志里筛出对配置类文件的成功请求 awk -F $9 200 $5 ~ /\.(config|bak|old|zip|orig)$/ {print $1, $4, $5, $7} \ u_ex*.log | sort | uniq -c | sort -rn | head -50 # 统计单位时间内 POST 请求体大小的异常分布 awk -F $5 POST {print $1, $8} u_ex*.log \ | awk {sum[$1]$2; cnt[$1]} END {for (i in sum) print i, sum[i]/cnt[i], cnt[i]} \ | sort -k2 -rn | head -20除了日志还要看文件系统。攻击成功后最常见的落地动作是往站点目录写文件所以检查bin、App_Data、上传目录、站点根目录下最近修改过的文件很有必要。重点关注后缀是.aspx、.ashx、.asmx、.config且创建时间集中在非发布时段的文件。另外 IIS 应用池账户对站点目录的写权限要单独审一遍很多站点为了方便上传直接给了Modify权限这等于给攻击者开了后门。5.3 一份可以直接照着做的自查清单把上面的内容整理成清单方便逐项打勾检查项检查方法判定标准配置文件是否可下载逐个尝试变体后缀并检查响应体响应体含配置标签即判泄露machineKey 是否 AutoGenerate读配置文件或脚本扫描生产环境出现即需处理validation 算法是否为老算法读配置SHA1/MD5 建议升级密钥长度是否达标数十六进制字符数对照第 2.3 节表格enableViewStateMac 是否关闭读pages节点出现 false 立即整改应用池账户权限查看站点目录 ACL非必要不授予写权限详细错误是否外泄访问一个不存在的路径看响应出现堆栈即需关闭站点目录是否有备份文件文件系统扫描存在即清理是否有异常落地文件按修改时间排序非发布时段新增文件需核实日志中是否有配置探测按后缀过滤大量命中即视为已探测这张表我在几次应急里都用过实际耗时大概半小时到一小时取决于站点数量。建议做成定期任务每月跑一次比出了事再查要省心得多。6. 加固与修复把这条链路从中间掐断6.1 应急状态下先做的三件事如果确认配置已经泄露不要犹豫按这个顺序来第一步立刻把泄露的文件从站点目录移走或者改名为不可访问的状态同时检查同目录下是否还有其他备份。这一步是止血虽然不能挽回已经发生的泄露但能防止持续暴露。第二步轮换machineKey。这是最关键的一步因为只要密钥还是老的攻击者手上的工具就依然有效。轮换的方式后面详细讲。轮换的同时把 Forms 认证的decryptionKey一起换掉其实它用的就是同一个machineKey这样所有已签发的认证 Cookie 全部失效攻击者没法拿着伪造的 Cookie 继续访问。第三步排查落地痕迹。按第 5.2 节的方法查文件系统和日志重点看泄露发生之后到轮换之前的这段时间窗口内有没有可疑的文件写入、进程创建、异常登录。这一步决定要不要升级为完整的事件响应。顺序不能反。有些团队习惯先排查再处置结果排查过程中攻击者一直在利用泄露的密钥等于边救火边浇油。6.2 machineKey 的正确生成与轮换姿势生成高强度密钥不要用脑补的字符串也不要用在线生成器谁知道它有没有留底。本机生成最稳妥# 生成 64 字节128 个十六进制字符的 validationKey function New-HexKey([int]$byteLength) { $bytes New-Object byte[] $byteLength [System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes) ($bytes | ForEach-Object { $_.ToString(X2) }) -join } $validationKey New-HexKey 64 # 对应 HMACSHA256/HMACSHA512 $decryptionKey New-HexKey 32 # 对应 AES-256 Write-Host validationKey$validationKey Write-Host decryptionKey$decryptionKey拿到两串字符后写进配置system.web machineKey validationKey上一步生成的128位字符 decryptionKey上一步生成的64位字符 validationHMACSHA256 decryptionAES / pages enableViewStateMactrue viewStateEncryptionModeAuto / customErrors modeOn defaultRedirect/error.html / /system.web轮换的时候有几个坑必须提前想到。第一所有节点必须同步换负载均衡后面挂几台机器密钥就必须完全一致否则请求打到不同节点会随机失败。第二会话会全部失效用户需要重新登录如果是在业务高峰期做要提前通知。第三有些加密字段会解不开如果业务代码里用machineKey加密了持久化数据比如存在数据库里的敏感字段换密钥之后这些数据就废了这种情况必须先做数据迁移或者保留旧密钥做兼容解密。第四改动需要重启应用池配置节的变更不会热生效。注意轮换前一定要在测试环境验证一遍完整流程尤其是涉及多节点和持久化加密数据的场景。我见过不止一次因为漏掉某个节点导致线上随机 500 的事故。6.3 配置文件访问控制的层层设防密钥轮换是治标防止泄露是治本。IIS 层面有几层配置可以做建议全部开启system.webServer security requestFiltering !-- 禁止访问配置文件及其常见变体 -- fileExtensions add fileExtension.config allowedfalse / add fileExtension.bak allowedfalse / add fileExtension.old allowedfalse / add fileExtension.orig allowedfalse / add fileExtension.zip allowedfalse / /fileExtensions hiddenSegments add segmentApp_Data / add segment.git / add segment.svn / /hiddenSegments /requestFiltering /security /system.webServer这里要注意fileExtensions的allowedfalse是全局生效的如果你的站点确实需要对外提供.zip下载比如导出功能要单独给对应目录开白名单而不是整体放开。除了 IIS 配置部署流程也要改。发布脚本里加一步清理残留文件把*.bak、*.old、*.zip、*.log全部删掉再上线。这一步看似琐碎但能挡掉大部分低级泄露。另外建议把配置文件和站点目录物理分离配置文件放在站点目录之外通过配置节引用或者环境变量注入这样即使目录被遍历也拿不到配置。6.4 纵深防御从请求层到运行时的兜底MAC 校验是核心但不能只靠它。我的建议是至少铺三层第一层是请求层。WAF 上加规则拦截 URL 里带.config、.bak等后缀的请求对 POST 请求体大小设阈值超过阈值的直接拒绝或者挑战验证对短时间内同一 IP 的高频 POST 做限速。这些规则会误伤正常业务吗一般不会正常的表单提交不会触发这些特征。第二层是应用层。除了enableViewStateMac还可以考虑把不需要 ViewState 的页面直接关掉EnableViewStatefalse减少攻击面。对于纯展示型页面ViewState 本来就是浪费带宽。另外把customErrors设为On统一错误页不给攻击者任何堆栈信息。第三层是运行时。应用池账户降权是性价比最高的一条让IIS_IUSRS只有读和执行权限没有写权限上传目录单独开一个受限目录并禁止执行脚本。这样即使 gadget 链触发攻击者也写不进可执行文件最多往上传目录丢个文本。再配合文件完整性监控站点目录一旦有非预期变更就告警响应速度会快很多。7. 踩坑记录与常见问题速查7.1 换完密钥之后的一连串连锁反应密钥轮换这件事说起来就两行配置做起来能踩出一串坑。我把自己和同行踩过的整理一下。最典型的是 Forms 认证集体掉线。machineKey同时用于 Forms 认证票据的加密和签名换了密钥所有已签发的 Cookie 全部失效用户下次请求就被踢回登录页。如果站点有记住我功能用户会发现明明勾了记住我第二天来又要重新登录。这个不是 bug是预期行为但必须在变更窗口内提前通知最好选在低峰期做。第二个坑是分布式缓存里的会话数据。如果用了基于machineKey加密的会话状态比如 StateServer 或者自定义的加密 Cookie换密钥之后旧数据解不开表现为随机的解密异常。处理方式是清空会话存储让用户重新建立会话。第三个坑是加密的持久化字段。有些业务会把敏感信息用machineKey加密后存进数据库比如用户的身份证号、银行卡号。换密钥之后这些字段全部解不开读出来是乱码或者直接抛异常。这种情况必须在换密钥之前先做一次全量解密重加密或者保留旧密钥做双密钥兼容。我在一个项目里就遇到过因为漏了一个表上线后那块功能直接不可用回滚折腾了两个小时。第四个坑是节点不同步。负载均衡后面三台机器只改了两台剩下一台还在用旧密钥。表现是用户刷新几次就掉线一次日志里全是 MAC 校验失败。这个问题的排查成本很高因为现象是随机的容易误判成网络问题。7.2 多节点与 Web Garden 下的密钥一致性单机部署的密钥管理很简单写死在web.config里就行。多节点就麻烦了必须保证所有节点用完全相同的密钥否则前面说的随机失败就会出现。常见的做法有三种。第一种是把machineKey写在每台机器的web.config里靠配置管理工具比如配置中心或者自动化部署脚本保证一致。这种方式简单直接缺点是密钥散落在每台机器上任何一台被攻破都会导致全部失守。第二种是把machineKey放在共享配置里所有节点通过网络路径读取。这种方式一致性好但引入了单点依赖共享路径不可用的时候所有站点都起不来。第三种是用密钥托管服务启动时拉取密钥注入到配置里。这种方式安全性最好但改造成本高老项目一般不愿意动。我的建议是按资产重要性分级核心系统上密钥托管一般系统用配置中心统一下发边缘系统写死但要做好文件权限。不管用哪种都要建立一个密钥变更流程包括变更前的影响评估、变更中的灰度验证、变更后的回滚预案。还有一个容易被忽视的点Web Garden 模式同一个应用池开多个工作进程。这种模式下每个工作进程的内存里都有一份密钥缓存如果密钥是AutoGenerate不同进程生成的密钥可能不一样导致同一个用户在不同进程间切换时校验失败。所以只要开了 Web GardenmachineKey就必须显式配置。7.3 常见问题速查表现象可能原因处理方式用户随机掉登录多节点密钥不一致统一所有节点的 machineKey页面报 MAC 校验失败密钥变更未同步或 ViewState 被改检查节点配置一致性排查代理篡改换密钥后加密字段乱码持久化数据用旧密钥加密迁移数据或保留旧密钥做兼容解密应用池启动即报错密钥长度与算法不匹配对照第 2.3 节表格重新生成上传功能突然不可用requestFiltering 拦截了 .zip给上传目录单独开白名单站点目录出现陌生 .aspx已被利用落地立即隔离主机走完整应急流程日志里大量 config 探测已被扫描确认无泄露加固过滤规则AutoGenerate 下重启失效密钥随进程变化改为显式配置并纳入配置管理最后分享一个我自己养成的习惯每次做这类漏洞复盘我都会在文章或者笔记的最后留一行这个结论在什么条件下会失效。比如MAC 校验能拦住反序列化这个结论失效条件就是密钥泄露和enableViewStateMac 被关闭而后者在新版本里已经被强制前者才是真正的软肋。把失效条件写清楚比记住结论本身更有用因为下次遇到类似场景你会先去看那些条件成不成立而不是套用上次的答案。这条链路的本质从来不是某个具体的技术细节而是信任边界被打破之后下游所有校验都会失效——密钥是信任的根根一旦暴露上面盖多高的楼都没意义。