防御 SQL 注入的方法和技术
我有一些用 C# 编写的 WinForms 应用程序（开发一些简单应用程序的框架）。我的框架后来将用于开发win form应用程序。其他开发人员通常是初学者，有时不使用参数 - 他们在代码中直接编写 SQL。因此，首先我需要以某种方式在 C# 中的框架基类中进行保护。 要解决这个问题，一位开发人员建议我使用 ORM，例如 NHibernate，它会为您解决这个问题（并且大多数时候您不必自己编写 SQL 语句）。 所以我想问，当我想防御 SQL 注入时，是否有一些通用的替代方案（其他方法和技术）。一些链接或示例会非常好。
i have some WinForms app (Framework to develop some simple apps), written in C#. My framework later would be used to develop win forms applications. Other developers they are beginers often and sometimes do not use Parameters - they write direct SQL in code. So first i need somehow to do protection in my framework base classes in C#.
Do solve this, one developer suggested me to using an ORM such as NHibernate, which takes care of this issue for you (and you don't have to write SQL statements yourself most of the time).
So I want to ask, is there some general alternatives(other ways and techniques) when i want to get defense from SQL-injections.Some links or examples would be very nice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不明白如何有任何方法可以保护任何基于 SQL 的库免遭开发人员误用，而又不会削弱其功能（即从不直接访问数据库）。
即使使用 NHibernate 或 Linq to SQL，也可以绕过映射层并直接编写 SQL 语句。
就我个人而言，我认为您最好的选择是用大粗体文本编写，使用您的库的人需要参数化他们的查询。如果做不到这一点，您可以尝试进行某种笨拙的输入清理，但这实际上是一个脆弱的二流黑客。
参数化查询已经存在了很长时间，任何编写涉及任何数据库的代码的人都没有理由不知道它或不了解如何使用它。治疗无知的唯一方法是教育。
也许如果我们更多地了解这个库在数据访问方面应该做什么，我们可以提供更有针对性的建议......
I don't see how there is any means to protect any SQL-based library from developer misuse without crippling its functionality (i.e. never giving direct access to the database).
Even with NHibernate or Linq to SQL it's possible to bypass the mapping layers and directly write a SQL statement.
Personally I think your best option would be to write in BIG BOLD TEXT that people who use your library need to PARAMETERIZE THEIR QUERIES. Failing that, you could try to do some kind of clumsy input sanitization, but that is honestly a flimsy second-rate hack.
Parameterized queries have been around for so long now, there's no excuse for anyone writing code that touches any database to not be aware of it or understand how to use it. The only cure for ignorance is education.
Maybe if we knew more about what this library is supposed to do with respect to data access, we could offer more targeted suggestions...
同意 Aaronaught 的观点，框架并不能完全阻止这种可能性。我永远不会替代数据层上的严格验证。还提供围绕数据访问的抽象层，您将其作为 API 开放，而不是允许开发人员直接连接到数据库。
Agree with Aaronaught, a framework will not completely prevent the possibility. I would never substitute stringent validation on the data layer. Also provide an abstraction layer around your data access that you open up as the API rather then allow developers to connect directly to database.
听起来您需要培训开发人员使用参数绑定，而不是寻找技术解决方案。
另一种选择是将数据库层保留在不同的项目中，并且只允许精通 SQL 的开发人员在其中进行编码。 GUI 可以位于不同的项目中。这样 GUI 程序员就不会弄乱你的数据库。
It sounds like you need to train your developers to use parameter binding instead of looking for a technical solution.
One other alternative would be to keep the database layer in a different project and only allow your SQL savy developers to code in it. The GUI can be in a different project. That way the GUI programmers won't mess up your DB.
安全性通常是一个过程，而不是一个产品或 API。
这也是一个不断发展的过程，我们必须适应，否则就会被黑客攻击。
严厉的方法：
你可以强制每个人都写存储过程，并且不允许
从允许与之交谈的帐户直接访问表
数据库。 （GRANT EXECUTE ON 等）
然后您需要确保没有人编写任何花哨的存储过程
将 sql 查询作为参数并动态评估它。
这往往会减慢开发速度，我个人不会使用它，
但我咨询过几家这样做的商店。
Security is usually a process, not a product or api.
It is also an evolving process, we have to adapt or get hacked.
A heavy handed approach:
You can force everyone to write stored procedures,and not allow
direct table access from the accounts that are allowed to talk to
the database. (GRANT EXECUTE ON etc)
Then you would need to ensure that nobody writes any fancy stored procedures
that take a sql query as a parameter and evaluates it dynamically.
This tends to slow down development, and I personally would not use it,
but I have consulted at several shops that did.