loading写给那些ASP.NET程序员：网站中的安全问题-电
脑资料
１：SQL注入 ２：XSS ３：CSRF ４：文件上传 １：SQL注入 引起原因：
其实现在很多网站中都存在这种问题。就是程序中直接进行SQL语句拼接。可能有些读者不太明白。下面通过一个登录时对用户验证来说明：
code:
验证时的sql语
句:select*fromwhereuser='\Pwd.Text+\
这是一段从数据库中查询用户，对用户名，密码验证。
看上去好象没有什么问题，但是实际这里面浅藏着问题，用户名：admin密码：admin，
select*fromwhereuser='admin'andpwd='admin'
如果用户和密码正确就可通验证。如果我用户名：asdf'or1=1--密码：随意输入.
我们再来看语句：
select*fromwhereuser=‘asdf'or1=1--andpwd=''
执行后看到什么？是不是所有记录，如果程序只是简单判断返回的条数，这种方法就可以通验证。
解决方法：
（１）：这个问题主要是由于传入特殊字符引起的我们可以在对输入的用户名密码进入过滤特殊字符处理。
（２）：使用存储过程通过传入参数的方法可解决此类问题（注意：在存储过程中不可使用拼接实现，不然和没用存储过和是一样的）。
２：XSS（跨站脚本攻击） 引起原因：
这个也有时被人们称作HTML注入，和sql注入原理相似，也是没有特殊字符进行处理。是用户可以提交HTML标签对网站进行重新的构造。其实在默认的情况下在asp.net网页中是开启
validateRequest属性的，所有HTML标签后会.NET都会验证：
但这样直接把异常抛给用户，多少用户体验就不好。 解决方法：
（１）：通过在Page指令或配置节中设置
validateRequest=false禁用请求验证，然后我们对用户提交的数据进行HtmlEncode,编码后的就不会出现这种问题了（ASP.NET中编码方法：Server.HtmlEncode(string)）。
（２）：第二种是过滤特殊字符，这种方法就不太提倡了，如果用户想输入小于号（<）也会被过滤掉.
３：CSRF（跨站点请求伪造）
引起原因：个人认为csrf在Ajax盛行的今天来说，倒是方便了，因为它可以在你不知道的情况用你的通过验证用户进行操作，所以
也被称为浏览器劫持。如果你已通过某个网站的验证那么你将以你的角色对网站进行操作，比如你是管理员可以添加其它的用户到管理组，但是如果有人构造了添加管理员的链接被管理员点后也会执行相应操作.具体原因可参考lake2写的文章CSRF--攻击与防御
解决方法：
在lake2的文章中也提出了。就是修改信息时添加验证码。或添加Session令牌（ASP.NET中已经提供一个自动防范的方法，就是用页面属性ViewStateUserKey.在Page_Init方法中设置其值。this.ViewStateUserKey=Session.SessionID）。
４：文件上传 引起原因：
如果你的网站使用的是在线编辑器，如FCKEditor,eWeb等等，如果没有处理好文件上传，那么上线后网站会很快的被篡改。
解决方法：
其实我在以前的笔记中曾写过这类文章：FCKEditor编辑器安全配置