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

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

我可以发送的字符串被强制为大写,最多可以包含26个字符.因此,我无法发送DROP TABLE,因为表名将为大写,因此语句将由于排序规则而失败.

那么 – 我在26个角色中可以造成的最大伤害是什么？

编辑

我知道关于参数化查询的所有信息等等 – 让我们想象一下,开发构建要发送的查询的前端的人在这种情况下不使用参数.

我也没有试图做任何邪恶的事情,这是一个由同一组织中的其他人建立的系统.

解决方法

简单：

GRANT EXECUTE TO LowlyDBA

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

grant execute to lowlydba

您可以选择相应的变化.

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

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

编辑：

对于恶意/有趣,您可以尝试启用每个跟踪标记.这将是有趣的观察.像Brent Ozar的博客文章一样会让…

DBCC TRACEON(xxxx,-1)