关于sql注入的危害在这里就不多搞介绍了，坚信大家也知道其中的厉害关系。这里存有一些sql注入的事件大家感兴趣可以看一下

防范sql注入的方法无非有以下几种：

1.采用类型安全的SQL参数
2.使用参数化输入存储过程
3.使用参数集合与动态SQL
4.输入滤波
5.过滤器LIKE条款的特殊字符

...如果存有遗漏的也热烈欢迎园子的大大们指教。

var Shipcity;
ShipCity = Request.form ("ShipCity");var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

上面是一个直观的sql转化成示例

用户将被提示输出一个市县名称。如果用户输出 Redmond，则查询将由与下面内容相似的脚本共同组成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

但是，假设用户输出以下内容：

Redmond'; drop table OrdersTable--

此时，脚本将组成以下查询：

1 SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分号 (;) 表示一个查询的完结和另一个查询的开始。双连字符 (--) 指示当前行余下的部分是一个注释，必须忽略。如果修正后的代码语法正确，则服务器将继续执行该代码。SQL Server 处置该语句时，SQL Server 将首先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。然后，SQL Server 将删除 OrdersTable。

只要注入的 SQL 代码语法恰当，便无法使用编程方式去检测篡改。因此，必须检验所有用户输入，并仔细检查在您所用的服务器中执行结构 SQL 命令的代码。本主题中的以下各部分说明了撰写代码的最佳作法。

下面就了解一下常用的几种防止sql转化成的方法：

1. 检验所有输入

始终通过测试类型、长度、格式和范围来检验用户输出。实现对恶意输入的防治时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应当被视作最佳做法：

对应用程序接收的数据不搞任何有关大小、类型或内容的假设。比如，您应该进行以下评估：

如果一个用户在需要邮政编码的位置无意中或蓄意地输入了一个 10 MB 的 MPEG 文件，应用程序可以做出什么反应？

如果在文本字段中嵌入了一个 DROP TABLE 语句，应用程序会做出什么反应？

测试输入的大小和数据类型，强制执行适当的限制。这有利于防止急于导致的缓冲区外溢。

测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于避免脚本注入，避免某些缓冲区外溢反击。

采用 XML 文档时，根据数据的架构对输入的所有数据展开检验。

绝不直接采用用户输入内容来生成 Transact-SQL 语句。

采用存储过程去验证用户输入。

在多层环境中，所有数据都必须在验证之后才允许步入可信区域。未通过验证过程的数据应当被拒绝，并向前一层返回一个错误。

同时实现多层验证。对并无目的的恶意用户实行的预防措施对始终如一的攻击者可能将无效。更好的作法是在用户界面和所有横跨信任边界的后续点上验证输出。

例如，在客户端应用程序中检验数据可以防止直观的脚本注入。但是，如果下一层指出其输出已通过检验，则任何可以绕开客户端的恶意用户就可以不受限制地访问系统。

绝不串联未检验的用户输出。字符串串联是脚本注入的主要输入点。

在可能据以结构文件名的字段中，不接受以下字符串：AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。

如果可能将，婉拒涵盖以下字符的输入。

用作目录拓展存储过程的名称的开头，如 xp_cmdshell。

注：验证输入就是最被常用和联想至的，但是个人感觉这种方式不但代码显得肥胖，而且效率不是较好

2.采用类型安全的 SQL 参数

SQL Server 中的 Parameters 子集提供更多了类型检查和长度验证。如果采用 Parameters 集合，则输入将被视作文字值而不是可执行代码。采用 Parameters 集合的另一个好处是可以强制执行类型和长度检查。范围以外的值将触发异常。以下代码段显示了如何使用 Parameters 子集：

1 SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);2 myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;3 SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",4      SqlDbType.VarChar, 11);5 parm.Value = Login.Text;

在此示例中，@au_id 参数被视为文字值而不是可以继续执行代码。将对此值展开类型和长度检查。如果 @au_id 值不合乎指定的类型和长度约束，则将引发异常。

存储过程如果采用未甄选的输出，则可能将容易受 SQL Injection 反击。例如，以下代码难受反击：

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + Login.Text + "'", conn);

如果使用存储过程，则应当使用参数作为存储过程的输出。

备注：在鄙人现在的项目中，这种方法应用最为广泛

3.在动态 SQL 中使用参数集合

如果不能使用存储过程，您仍可使用参数，如以下代码示例所示：

1 SqlDataAdapter myCommand = new SqlDataAdapter(2 "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);3 SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
4                         SqlDbType.VarChar, 11);5 Parm.Value = Login.Text;

备注：和第二种雷同，这种方法就是为了补充方法2存有，因为往往在很多时候业务直观不须要用proc的时候，可以用这种方法

4.甄选输入

筛选输出可以删掉转义符，这也可能将有助于防止 SQL 注入。但由于可引发问题的字符数量很大，因此这并不是一种可信的防护方法。以下示例可以搜索字符串分隔符。

1 private string SafeSqlLiteral(string inputSQL)2 {3   return inputSQL.Replace("'", "''");4 }

备注：Filtering Input有种类似方法1

5.LIKE 子句

请注意，如果要使用 LIKE 子句，还必须对通配符字符进行换行：

1  2 s = s.Replace("[", "[[]");3 s = s.Replace("%", "[%]");4 s = s.Replace("_", "[_]");

注：针对like子句，在使用时的效率这里就不多说道了，总之必须禁用了。