使用本机数据库登录/用户时的SQL注入

在开发一个应用程序时，如果用户使用本机数据库登录进行连接，我就不需要关心SQL注入了，对吗？原因是用户无论如何都可以执行他们想要的任何SQL。（有些地方管理员执行CREATE LOGIN和CREATE USER语句，这些语句必须动态生成。）我说的是局域网上的本机Windows应用程序。

好的，SQL注入是执行SQL的一种可能，因此通过SQL shell访问，“SQL注入”所需的一切都已经得到授权。但是，您仍然需要注意用户是否以非管理员身份运行，可能会限制他们可以访问哪些表，并且您的系统在以更高权限（创建用户等）登录时会发送一些额外的SQL命令。用于此类代码。

如果您的意思是要构建web应用程序，并使用用户的数据库凭据连接到数据库，那么您确实需要担心SQL注入

大多数数据库基于对象（表、视图、存储过程等）限制权限。因此，以“Bob”身份登录的用户可能可以访问表“sales”，但不能访问表“payments”

数据库不限制对表中的行的访问（例如）。因此，作为“Bob”连接的用户可以利用代码中的SQL注入错误删除“sales”表中的每条记录。你可能不想那样

如果用户“Bob”也具有直接SQL访问权限，那么他们当然可以在SQL命令行上运行该语句——但通常，web应用程序在没有直接SQL访问权限的地方可用。您的web应用程序可能一开始就放在intranet上，但您不能保证将来不会被打开

考虑到在构建应用程序时防止SQL注入攻击是多么容易，以及以后修复它们是多么痛苦，我认为没有真正的理由不首先阻止它们

事实上，“SQL注入”是一个常见的误解。
由于无法正确格式化查询，人们发明了“sql注入”作为借口。
虽然格式正确，但查询将同时用于两个目的：

• 无论发送什么数据，它在语法上总是正确的
• 作为一个副作用，它将是无懈可击的臭名昭著的“SQL注入”的事情

我怀疑你希望你的查询因为一些意外的符号而失败。因此，无论是什么“注入”，都必须正确格式化。但一旦格式化，无论如何都不会有注入。因此，您必须关注格式，而不是注入

---

我还觉得让用户使用数据库凭据登录不是一个好主意。

这是一个直接连接到数据库的局域网应用程序。将适当的权限授予每个用户在DBA中的角色。我只关心除了使用动态SQL之外别无选择的语句。其他一切都是通过ORM或参数化的。应用程序将始终只与用户自己的帐户连接。用户将处于已分配适当权限的角色中。在SQL Server中，动态SQL始终在连接用户的上下文中执行，即使它在过程中也是如此。有几个命令不接受参数，只接受字符串。