在 Winforms 项目中担心 SQL 注入有什么意义吗？答案

【问题标题】：Is there any sense in worrying about SQL injection in a Winforms project?在 Winforms 项目中担心 SQL 注入有什么意义吗？
【发布时间】：2010-01-12 23:33:11
【问题描述】：

在 SO 和其他地方，如果没有人礼貌地指出最好使用参数化输入和存储过程，几乎不可能在示例代码中发布长连接的 SQL 指令。

最近的例子here。

但是在 Winforms 项目中担心 SQL 注入有意义吗？

【问题讨论】：

我礼貌地同意这个答案 owner =)

标签： winforms sql-injection

【解决方案1】：

有什么理由不编写安全的数据库代码吗？我不这么认为。

每个人都应该养成安全执行 SQL 的习惯，这样你在编写公共应用程序时甚至都不必考虑它。

还要考虑到，许多原本打算私有的代码最终会在几个月或几年后公开访问。例如，“嘿，这个用于库存报告的 Intranet 应用很有用，我们为什么不将它上传到我们的公共网站供我们的业务合作伙伴使用？”

使用参数将未经验证的数据与 SQL 查询分开。
您可以将已验证数据插入到 SQL 查询中。也就是说，如果您有代码来测试变量只能是整数（例如），那么将其视为整数是安全的。
对于查询的其他动态部分（表名、列名、表达式等），您不能使用查询参数。但是您可以将用户输入映射到硬编码字符串。例如。如果用户输入1，则按date 列排序。如果用户输入2，则按status 列排序。
忽略那些说“只使用存储过程！”的程序员。好像这与防御 SQL 注入有关。没有。

【讨论】：

+1;如果您即使在桌面应用程序中也不关心 SQL 注入，那么迟早，“您所有的 _data_base 都属于我们”

【解决方案2】：

现实生活中的史诗：中西部公司的大老板来看项目进展。不知道它是怎么发生的，但不知何故，调度办公室为一位从未见过的客户下了一组新订单。并且在Boss来看的时候投产了。他的姓是 O'Shaughnessy。

使用参数化输入不仅仅可以避免 SQL 注入。

【讨论】：

我认为这确实符合 SQL 注入的定义，尽管它是偶然的而不是恶意的。
我想我的问题应该区分恶意和意外。当然，winforms 应用程序必须防范后者。有一些方法可以保护 winforms 应用程序免受“O'Shaughnessy”错误的影响，从理论上讲，它仍然容易受到其他类型的攻击

【解决方案3】：

是的，出于您在其他项目中看到的所有原因。

您的用户群可能较小，但存在同样的危险。

【讨论】：

并不是用户群变小，而是用户群——通常——与数据库有着完全不同的关系。通常它在任何意义上都是“他们的”数据库。他们不想搞砸它。事实上他们拥有它。
他们也拥有备份程序吗？
SQL 注入不一定是恶意的，它可能是利用应用程序对输入的松懈处理而发生的诚实事故。