预防SQL注入攻击之我见

1、 SQL注入攻击的本质：让客户端传递过去的字符串变成SQL语句，而且能够被执行。
2、 每个程序员都必须肩负起防止SQL注入攻击的责任。
　　说起防止SQL注入攻击，感觉很郁闷，这么多年了大家一直在讨论，也一直在争论，可是到了现在似乎还是没有定论。当不知道注入原理的时候会觉得很神奇，怎么就被注入了呢？会觉得很难预防。但是当知道了注入原理之后预防不就是很简单的事情了吗？
　　第一次听说SQL注入攻击的时候还是在2004年（好像得知的比较晚），那是还是在写asp呢。在一次写代码的时候，有同事问我，你的这段代码防注入攻击了吗？什么攻击？这是什么呀。
　　后来到网上各种找，终于弄明白了是怎么攻击进来的了。注入攻击都是来自于客户端，无论是表单提交、URL传值还是Cookie等，其实原理都是一样的。到了服务器端可以分成三种情况：数字、日期时间、字符串。
一、数字。
　　如何注入？
　　假设我们要实现一个显示新闻的页面，我们可能会随手写下下面的代码：
string id = Request.QueryString["id"];
string sql = "select * from news where ColID=" + id;
　　如果传递过来的 id是我们想像的 数字（比如168），那么自然不会有什么问题。但是如果传递过来的id是“168 delete from table ”的话，那么sql的值就变成了“select * from table where ColID=168 delete from news”。对于SQL Server来说是支持一次提交多条SQL语句的，这个为我们提供了方便之余也为SQL注入敞开了大门。显然如果这条SQL语句被执行的话，那么news表里的记录就都没有了。
　那么如何预防呢？很简单，因为ColID字段的类型是int的，那么我们只需要验证一下传递过来的id是不是整数就可以了。是整数就不存在注入；如果不是那么就有可能存在注入。即使不存在注入，把一个不是整数的id拼接进去也会造成执行错误。
　　所以说不管是不是为了预防SQL注入，也都应该验证id是不是整数。　　
　　验证方法嘛，可以用TryParse，可以用正则，也可以自己写函数验证。但是不建议用try异常的方式，因为这个有效率问题。
　　这里还有一个特殊情况，就是对于批量删除这类的会传递过来多个数字，比如“1，2，3，10”，这个也需要验证一下，万一有人利用这个漏洞呢。至于验证方法也很简单，自己写个函数就ok了。
二、日期时间
　　这个和数字的情况是一