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

-2

在开发用户连接其本机数据库登录名的应用程序时，我不需要关心SQL注入权吗？原因是用户可以执行他们想要的任何SQL。（有些地方管理员执行CREATE LOGIN和CREATE USER语句，这些语句必须动态构建。）我正在谈论LAN上的本地Windows应用程序。使用本机数据库登录/用户时的SQL注入

来源

2012-12-28 Monstieur

嘛，SQL注入是执行SQL的可能性，所以用SQL shell访问，为“SQL注入”所需的一切已经授权。但是，如果用户以非管理员身份运行，可能会限制他们可以访问哪些表，并且系统在以更高权限（创建用户等）登录时发送一些其他SQL命令，您仍然需要关心。使用prepared statements作为这样的代码。

来源

2012-12-28 08:08:18 h22

应用程序将始终与用户自己的帐户连接。用户将处于具有相应权限的角色中。在SQL Server中，动态SQL始终在连接用户的上下文中执行，即使它在过程中。 – Monstieur

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

大多数数据库基于对象的限制权限 - 表，视图，存储过程等，所以，用户登录为“鲍勃”可能访问到餐桌“销售”，而不是表“支付”。

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

如果用户“鲍勃”也有直接的SQL访问，他们当然可以，只需运行在SQL命令行语句 - 但通常，Web应用程序都可以在那里直接SQL访问是没有的。您的网络应用程序可能会放在Intranet上，但您无法保证将来不会打开该应用程序。

鉴于它是多么容易防止SQL注入攻击，当你正在构建的应用程序，它是什么一个痛苦的解决这些问题以后，我看不出有什么真正的原因不是为了防止它们摆在首位。

来源

2012-12-28 08:15:12

这是一个直接连接到数据库的LAN应用程序。适当的权限授予每个用户将在DBA中的角色。 – Monstieur

我只关注语句，我别无选择，只能使用动态SQL。其他一切都是通过ORM或参数化。 – Monstieur

事实上，“SQL注入”是一个常见的误解。
由于无法正确格式他们的查询，人们发明了一个“sql注入”的事情作为借口。
虽然格式正确的查询将成为2种用途一次：

它永远是语法正确的，不管发送的是什么数据
的副作用将是无懈可击的那臭名昭著的“SQL注入“的东西。

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

我也有一种感觉，让用户使用数据库凭证登录不是一个好主意。

来源

2012-12-28 09:01:09

有几个命令不接受参数，只接受字符串。 – Monstieur

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

回答

相关问题