在这个问题上已经有了很好的答案，但是我想再提一些：

• 安全编码（许多人已经提到过）
  • 转义用户输入
  • 参数化查询（准备好的语句，只绑定变量的预定义查询）
  • 防御性代码
• 监控攻击
  • 网络入侵检测系统 (NIDS)
  • 主机入侵检测系统 (HIDS)
  • 应用入侵检测系统（AppIDS）
• 阻止攻击
  • 应用防火墙
  • 数据库防火墙
  • 网络应用防火墙
    • 阿帕奇国防部安全
    • 思科应用速度系统 (AVS)
• 漏洞探测
  • 自动化黑盒注入测试
  • 静态源码分析
  • 手动渗透测试

这只是为了预防，我没有考虑到sql server 加固。然而有很多相似之处。

如果您已经容易受到注射，其他防御措施将是：

• 以最少的授权量运行您的应用程序
  • 专门授予对您需要的数据库和表的访问权限
  • 确保只授予它需要的权限（通常是选择、插入、更新）

准备好的语句、参数化查询、转义所有用户输入，对于一个好的初学者，请参阅http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet。

关键的防御是只使用安全地逃避数据库查询的 API——这些通常被称为参数化或准备好的语句。这些不能在所有情况下都使用（例如，在运行时提供诸如表或列名之类的 SQL 标识符时），但在可能的情况下是最好的方法（大多数情况下）。

注意 - 这可能会导致将有害数据放​​入数据库中，因此在应用程序的其他地方使用此数据时请注意这一点

第二道防线是采取逃避的方式。这就是“用两个引号代替一个引号”的方法。如果您需要这样做，则必须转义每个可能有害的字符，这在某些情况下意味着不止单引号。如果可能的话，我建议使用更高级别的库，例如 OWASP ESAPI，或者仔细阅读 OWASP SQL 注入备忘单（上面引用过）。

• 在这里你可以找到一些SQL 注入资源
• 下面是一些SQL 注入攻击的例子
• 以下是一些如何保护您的应用程序免受 SQL 注入攻击的基础知识

保护 Web 应用程序免受 SQL 注入攻击的主要步骤是正确清理任何用户输入（尤其是 SQL 查询中使用的输入）。在某些语言/框架中，有一些标准方法可以处理这些值 - 例如使用参数化查询而不是通过连接字符串值来组合查询。