SQL Server 注入 - 26 个字符中有多少损坏？

Question

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

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

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

那么 - 我可以在 26 个字符中造成的最大伤害是多少？

编辑

我对参数化查询等都了如指掌——让我们想象一下，在这种情况下，开发构建要发送的查询的前端的人没有使用参数。

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

Answer 1

简单：

GRANT EXECUTE TO LowlyDBA

或者，我想在这种情况下它会是

grant execute to lowlydba 

选择这方面的变化。

很可能您现在可以针对当前系统进行测试，但是随着时间的推移，数据库中的任何小变化都可能使您的测试无效。字符串可能会改变，有人可能会创建一个具有破坏性潜力的小写存储过程 - 任何东西。您永远无法 100% 自信地说不存在有人可以构建的破坏性 26 字符攻击。

我建议你找到一种方法让开发人员遵循基本的行业标准最佳安全实践，如果只是为了你自己，我认为如果发生安全漏洞，我认为至少要负部分责任。

编辑：

对于恶意/乐趣，您可以尝试启用每个跟踪标志。这将是有趣的观察。感觉就像布伦特·奥扎尔 (Brent Ozar) 的博客文章……

DBCC TRACEON(xxxx, -1)

Answer 2

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

Answer 3

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

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