在开发用户使用其本地数据库登录名连接的应用程序时，我不需要关心 SQL 注入，对吧？原因是用户无论如何都可以执行他们想要的任何 SQL。（有些地方管理员执行 CREATE LOGIN 和 CREATE USER 语句，这些语句必须动态构建。）我说的是 LAN 上的本地 Windows 应用程序。
问问题
162 次
3 回答
2
好吧，SQL 注入是执行 SQL 的一种可能性，因此通过 SQL shell 访问，“SQL 注入”所需的一切都已被授权。但是，您仍然需要注意用户是否以非管理员身份运行，可能会限制他们可以访问哪些表，并且您的系统会在以更高权限（创建用户等）登录时发送一些额外的 SQL 命令。对这样的代码使用准备好的语句。
于 2012-12-28T08:08:18.230 回答
0
如果您的意思是您正在构建一个 Web 应用程序，并使用用户的数据库凭据连接到数据库，是的，您确实需要担心 SQL 注入。
大多数数据库基于对象限制权限 - 表、视图、存储过程等。因此，以“Bob”身份登录的用户可能有权访问表“销售”，但不能访问表“付款”。
数据库不限制对表中行的访问（例如）。因此，作为“Bob”连接的用户可以利用代码中的 SQL 注入错误，可以删除“sales”表中的每条记录。你可能不想要那个。
如果用户“Bob”也具有直接 SQL 访问权限，他们当然可以在 SQL 命令行中简单地运行该语句 - 但通常，Web 应用程序在没有直接 SQL 访问权限的情况下可用。您的 Web 应用程序一开始可能会放在 Intranet 上，但您不能保证将来不会开放。
考虑到在构建应用程序时防止 SQL 注入攻击是多么容易，以及稍后修复它们是多么痛苦，我认为没有真正的理由不首先防止它们。
于 2012-12-28T08:15:12.390 回答
0
事实上，“SQL 注入”是一种常见的误解。
由于无法正确格式化查询，人们发明了“sql 注入”作为借口。
虽然格式正确的查询将同时达到 2 个目的：
- 无论发送什么数据，它在语法上总是正确的。
- 作为副作用，它不会受到臭名昭著的“SQL注入”的影响。
我怀疑您是否希望您的查询由于某些意外符号而失败。所以，不管是什么“注入”，你都必须正确格式化它。但是一旦格式化，无论如何都不会注入。因此，您必须关注格式，而不是注入。
我也有一种感觉，让用户使用数据库凭据登录并不是一个好主意。
于 2012-12-28T09:01:09.237 回答