sqlsever报错注入

sqlserver报错注入：一条报错信息就能拖库

报错注入在SQL Server里是报错最直接的一种注入手法。别的注入注入方式还得靠盲注逐字符猜，报错注入直接把数据塞进数据库的报错错误消息里甩给你。攻击者需要做的注入，就是报错让SQL语句报错，并且让报错内容带上他想要的注入数据。

先说个真实案例。报错去年我帮朋友排查一个后台管理系统，注入登录框对用户名做了简单的报错字符过滤，单引号被转义了。注入但密码框没过滤，报错而且密码框的注入报错信息直接回显到页面上。攻击者构造了这样的报错payload：' and 1=convert(int,(select top 1 name from sysobjects where xtype='u'))--。密码框里输入这段，注入系统报错：“将varchar数据类型转换为int数据类型时失败”，报错而错误信息里就带着第一个用户表的表名。

原理其实不复杂。SQL Server在执行convert(int, expression)时，如果expression是字符串且无法转换为整数，就会抛出转换错误。错误消息会包含原始字符串内容。攻击者把子查询的结果拼接到convert的第二个参数里，报错信息自然就把查询结果泄露出来了。

常用的报错函数不止convert一个。还有cast，用法类似。count(*)配合having也能触发报错，比如having 1=1在group by时会把列名带出来。更经典的是type属性相关的xml报错，用and 1=(select * from (select * from table1 as a join table1 as b) as c)这种自连接制造主键冲突，报错信息会包含重复的键值——也就是你查询的数据。

报错注入的局限也很明显。首先，它依赖数据库错误信息的完整回显。很多生产环境会屏蔽详细错误，只显示“服务器错误”之类的通用提示。其次，sqlserver的报错信息长度有限制，convert报错只能截取前256个字符，遇到长数据得用substring分段取。再者，报错注入的单次请求会触发大量数据库异常日志，安全设备很容易发现异常流量。

防御层面，最有效的还是参数化查询。所有用户输入直接作为参数传给SQL，数据库引擎就不会把输入当代码执行。如果用的是动态拼接SQL，那至少也得做严格的白名单过滤。还有一点容易被忽视：关闭数据库的详细错误回显。IIS或ASP.NET里设置customErrors mode="On"，页面就不会把堆栈信息暴露给客户端。但即便这样，攻击者还能通过时间盲注绕过——只是报错注入这条路堵死了，攻击成本会高很多。

报错注入之所以被低估，是因为很多开发者觉得“报错信息而已，泄露不了什么”。实际上，一张表的表名、一个用户的密码哈希，都可能通过这条路径流出去。我见过最极端的案例，攻击者用报错注入把整个数据库的所有表名、列名、甚至部分数据全拖走了，就靠一条条报错信息拼出来的。数据库的报错机制本来是帮人调试的，结果成了攻击者的数据通道。

写代码时多花十分钟用参数化查询，比事后修补漏洞省事得多。这个道理说了无数遍，但每次看到新的报错注入案例，还是有人中招。