.NET 一种尚未公开绕过 SQL 全局防注入拦截的方法

在.NET安全中，SQL注入攻击一直是安全领域的一个重要话题。尽管SQL注入的基础原理和常见手法在安全圈内已被广泛讨论和研究，最近在代码审计和实战演练中我们团队发现了一种全新的SQL注入绕过技巧。这种方法在公开的技术资料或安全文章中几乎未被提及，至少在国内现有的研究和文献中没有找到相关的描述。

在实战场景中，这种新的SQL注入绕过技巧可能在常见的安全审计工具和防御策略下成功触发注入漏洞，尤其是在与MSSQL数据库交互时，如果具备SA权限，攻击者甚至可以进一步将SQL注入漏洞扩展为远程代码执行，直接获取服务器的控制权限。

正因如此，我们认为有必要将这项研究成果分享出来，帮助开发者和安全研究人员在代码审计或攻防对抗中，提前识别和防范此类SQL注入绕过手法。本文将通过详细的技术分析和实战案例，深入剖析这种绕过技巧的原理和实现方式，帮助大家提升在.NET环境下的安全意识和防御能力。

01. 全局防注入配置

为了防止 SQL 注入攻击，很多.NET应用或者研发者会全局配置文件BeginRequest事件中通过字符串匹配的方式，对传入的请求参数进行全局性过滤。通过这种方式，可以在请求进入应用程序之前，主动检测和拦截潜在的 SQL 注入攻击。常见的防注入代码如下所示：

publicstaticstring sqlFilter ="exec|select|and|or|xor|order|mid|asc|execute|xp_cmdshell|insert|update|delete|join|declare|char|'|;|--";

此处定义了一个全局的 sqlFilter 列表，其中包含了常见的 SQL 注入关键字，比如 select, insert, delete, xp_cmdshell 等。

接着，在 Application_BeginRequest 事件中，程序会在请求开始时检查 QueryString 和 Form 数据，判断其中是否包含 sqlFilter 定义的关键字。

string[] sqlFilterArray = sqlFilter.Split('|');foreach(var key in sqlFilterArray){if(System.Web.HttpContext.Current.Request.QueryString !=null){for(int k =0; k < System.Web.HttpContext.Current.Request.QueryString.Count; k++){string getsqlkey = System.Web.HttpContext.Current.Request.QueryString.Keys[k];if(System.Web.HttpContext.Current.Request.QueryString[getsqlkey].ToLower().Contains(key)==true){                System.Web.HttpContext.Current.Response.Write("Detecting Attack");                System.Web.HttpContext.Current.Response.End();}}}if(System.Web.HttpContext.Current.Request.Form !=null){for(int k =0; k < System.Web.HttpContext.Current.Request.Form.Count; k++){string getsqlkey = System.Web.HttpContext.Current.Request.Form.Keys[k];if(System.Web.HttpContext.Current.Request.Form[getsqlkey].ToLower().Contains(key)==true){                System.Web.HttpContext.Current.Response.Write("Detecting Attack");                System.Web.HttpContext.Current.Response.End();}}}}

如果检测到可疑关键字，程序立即返回 "Detecting Attack" 消息，并终止请求。

除了 QueryString 和 Form 之外，攻击者还可能通过 Cookies 和 HTTP Headers 传入恶意的 SQL 注入语句。为了进一步强化防御能力，我们可以在上述代码基础上，增加对 Cookies 和 Headers 的检测。在理论上，已经构建了全局的 SQL 注入防御机制，看似滴水不漏。