动易安全手册
这就造成了SQL注入，条件永远为真，也就不用密码也能登陆成功。
3.2主要防御方式：
防御手段一:参数化查询
保护级别：★★★★★
描述:
使用参数化查询的好处：可以防止sql注入式攻击，提高程序执行效率。
例如:
const string strSql = "SELECT * FROM [PE_Users] WHERE UserName = @UserName";
Parameters parms = new Parameters("@UserName", DbType.String, userName);
中有一个参数@UserName, 使用Prarmeter对象，通过它把参数添加到Command对象上，这样就获得参数化查询。
如上述语句,ADO.NET 会向SQL Server 发送下面的SQL语句:
Exec sp_executesql N ‘select * from [pe_users] where username=@username ‘,N ‘@username nvarchar(20) ‘,@username=N ‘name’
SQL Server 把@username 替换成字符串”name”,然后再执行查询.
假设有下面的输入:
‘ union select @@version,null,null—
生成的SQL语句如下所示:
Exec sp_executesql N ‘select * from [pe_users] where username=@username ‘,N ‘@username nvarchar(20) ‘,@username=N ‘’’ union select @@version,null,null--’
可以看到ADO.NET转义了输入。
public SqlParameter Add(string parameterName, SqlDbType sqlDbType, int size);
DbTye或SqlDbType可以是多种数据类型。
可根据你的数据类型来选择。
在某些地方,也可似指定参数的长度:int size。这样也能有效防止数据库溢出和SQL注入的可能性。
优点：有效地防止了SQL注入的产生。
缺点：有些地方不能应用，如 in 。
防御手段二:过滤与转换
保护级别：★★★★
描述:
对于数据型要强制转换成数字Clng，对于字符型，要通过函数过滤。如：
private string SafeSqlLiteral(string inputSQL)
{
return inputSQL.Replace("'", "''");
}
对于搜索的地方LIKE 子句，要注意，如果要使用 LIKE 子句，还必须对通配符字符进行转义：
s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");
对于in类型，要转换成规格的数字串或字符串：
ToValidId 函数
UserNamefilter 函数
要尽量少用语句连接形式写SQL语句，要用到的地方要确保连接语句的安全性，或在白名单内，或限制很短的长度，以防止SQL语句构造的危险。
优点：有效地防止了SQL注入,实现简单。
缺点：容易遗漏，对于某些地方还是不能过滤，如 order by + 变量
防御手段三:白名单
保护级别：★★★★
描述:
对于一些已知的参数范围，可用白名单的形式处理，能有交防止SQL注入和查询出错，如：order by +列名，列名以参数形式传入时，可制定一个白名单，先判断一下参数是否在白名单内，再进行查询，否则出错处理。
优点：安全可靠
缺点：应用范围小.
3.3 辅助防御方式
防御手段一：严格过滤
保护级别：★★★☆
描述：
对于不能参数化查询或者无法限制变量类型和范围的情况，使用过滤的手段
DataSecurity.FilterBadChar来过滤。
对于数据库中读取的数量要进入查询语句，在不确定数据是否安全的情况下，要对其进入过滤。这种SQL注入比较隐蔽，所以要特别注意。
优点：能用于不能参数化而又难过滤的地方，如 order by +变量
缺点: 过滤过于严格。
防御手段二：限定URL传递参数的数据类型和范围
保护级别：★★★
描述：
限定URL的传递参数类型、数量、范围等来防止通过构造URL进行恶意攻击。需要在Config\QueryStrings.config配置文件中增加相应的配置项。参见MSDN杂志
优点：在一定的程序上有效地防止通过URL方式的注入。
缺点：容易遗忘正常需要的参数。
防御手段三：全局过滤SQL关键字过滤
保护级别：★★★
描述：
在某些地方进行全局过滤SQL关键字过滤 FilterSqlKeyword，如对标签的解释。（可能存在过滤不完全和限制程序开发的问题）
优点：能用于不能参数化而又难过滤的地方，如 table的连接。
缺点: 过滤过于严格。
更多关于SQL注入，可参考这篇文章：
http://www.microsoft.com/taiwan/msdn/columns/huang_jhong_cheng/LVSS.htm
四、 跨站脚本攻击
1. 什么是跨站脚本攻击
跨站脚本攻击(通常简写为XSS)是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
2. 跨站脚本攻击的危害
入侵者便通过技术手段在某个页面里插入一个恶意HTML代码，例如记录论坛保存的用户信息（Cookie），由于Cookie保存了完整的用户名和密码资料，用户就会遭受安全损失。如这句简单的Java脚本就能轻易获取用户信息：alert(document.cookie)，它会弹出一个包含用户信息的消息框。入侵者运用脚本就能把用户信息发送到他们自己的记录页面中，稍做分析便获取了用户的敏感信息。
跨站脚本攻击的危险，在如今WEB安全越来越得到重视，他的危险性也越来越大。有效防止跨站脚本攻击，是WEB程序是否安全的一个重要标准。
3. 如何防止跨站脚本攻击
3.1 主要防御方式
防御手段一：编码输出
保护级别：★★★★★
描述：
对于不支持HTML代码的地方，可用编码输出。如：HtmlEncode、Server.UrlEncode等方法编码输出。
优点：安全可靠。
缺点：不支持HTML代码。
防御手段二：使用UBB编码
保护级别：★★★★
描述：
UBB代码是HTML的一个变种,是Ultimate Bulletin Board (国外的一个BBS程序)采用的一种特殊的TAG。它能有效的限制HTML代码的使用，增强系统输出的安全性。
优点是：简单，容易实现，利用白名单形式，易于控制。
缺点是：只支持小量特定html代码，编辑器功能小。
3.2 辅助防御方式
防御手段一: iframe security="restricted"
保护级别：★★★★
描述：
通过设置iframe security="restricted",能有效防止iframe类的攻击(对IE有效).
优点：有效防止iframe的攻击。
防御手段二: HttpOnly
保护级别：★★★★
描述：
设置Cookie的HttpOnly属性，有效地防止Cookie通过脚本泄密（IE6 SP1以上、Firefox 3）。
优点：有效保护了用户Cookie信息。
防御手段三: 字符过滤
保护级别：★★★★
描述：
通过RemoveXss函数进行过滤，能有效防止常见脚站脚本的跨站攻击。主要过滤常见恶意脚本代码，
如：
<applet|meta|xml|blink|link|style|script|embed|object|iframe|frame|frameset|ilayer|layer|bgsound|title|base>
OnX事件代码、Javascript、Vbscript和Style中的expression、behaviour、script、position等。
但过滤可能存在不完全的情况。建立自己的XSS攻击库，方便测试和收集新的攻击方式，使过滤函数更加完善。
优点：支持HTML，有效防止大部份攻击代码。
缺点：可能存在过滤不全的情况。
4．XSS漏洞另一个攻击趋势
1）攻击的本质：
实际上这是一小段JAVASCRIPT，我们只是通过漏洞把这段JS感染到每一个用户的浏览器，但是他不再受系统的限制，任何一个有漏洞的浏览器访问了类似页面都会受到攻击。
2）传播的途径：
从传播方式上来说它和传统的网页木马攻击方式没有区别，由于这种攻击对于HTTP请求包括AJAX都没有域的限制，能使用浏览器本地保存的COOKIE，所以可以劫持用户所有WEB应用的身份，它完全能够让已感染主机配合任何网站的应用做蠕虫式的传播。
3）攻击的危害：
我们可以像传统的僵尸网络一样控制大量的浏览器肉鸡，控制浏览器做任意的访问行为和动作。同时也能针对单个用户做渗透攻击，劫持他所有WEB应用的身份，读取运行本地的任意敏感文件。
4）攻击的展望：
当Active X等溢出漏洞不再风光的时候，以后利用XSS漏洞针对浏览器进行劫持攻击将是一个大的趋势。
跨站脚本攻击，在web2.0时代的现在，越发体现出他的危险性，软件的漏洞加速了xss攻击的危险和加剧了这样攻击的利用。浏览器的漏洞也成为了现今热门的话题：
更多关于XSS攻击的文章请看：
http://www.80sec.com/
http://huaidan.org/
五、 跨站请求伪造
1. 什么是跨站请求伪造
CSRF（Cross-site request forgery跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
2. 跨站请求伪造的危害
不要低估了CSRF危害性和攻击能力！可以说，跨站请求伪造是跨站脚本攻击的一种深入利用，它的危害性更大。如：给自己提升权限，增加管理员等。可以通过网上的一个案例说明这种攻击的危害：
Bob在自己的电脑上刚刚查看完自己的银行A账户余额，然后比较无聊就跑到一个公开的BBS上灌水，当他看到一篇“银行A的内部照片”的帖子，很有兴趣的打开这个帖子想看看自己信任的银行A的内部图片是啥样子的，殊不知，这其实是一个attacker精心设计的骗局。在这个帖子中确实有几个图片，看上去真的像是银行A的照片，但是其中有个图片没显示出来，Bob以为是自己网速太慢，导致这个图片没有加载进来，也没在意。只是对这些并不是十分满意的照片摇摇头，就关了这个帖子。几天后，Bob猛然发现自己在银行A的账户上少了1000元，到底是怎么了？
设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的链接，并将此链接作为图片tag。如果Bob的银行在cookie中保存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。
3. 如何防止跨站请求伪造
3.1主要防御方式：
防御手段一：ViewStateUserKey（对应Post方式）
保护级别：★★★★
描述:
ViewStateUserKey 是 Page 类的一个字符串属性,设置Page.ViewStateUserKey 属性，防止出现跨站请求伪造攻击。如果攻击者使用视图状态创建预先填充的 Web 页（.htm 或 .aspx），则发生跨站请求伪造攻击。视图状态可根据攻击者先前创建的页面生成。例如，包含 100 种商品的购物车页面。攻击者可引诱信任用户浏览该页，然后将该页发送至视图状态有效的服务器。服务器不知道该视图状态是由攻击者生成的。由于视图状态的有效性，再加上页面在用户安全上下文中执行，因此视图状态验证和 MAC 无法对付这种攻击。为 Page.ViewStateUserKey 属性设置唯一适合的值，然后作为防止跨站请求伪造攻击的对策。对于每个用户而言，这个值必须唯一。通常，它是用户名或标识符。当攻击者创建视图状态时，常将 ViewStateUserKey 属性初始化为自己的用户名。当用户向服务器提交页面时，便使用攻击者的用户名对该页进行初始化。因此，视图状态 MAC 检查将失败，同时出现异常状况。
优点：有效防止POST方式的跨站请求伪造。
防御手段二：追加安全验证码（对应Get方式）
保护级别：★★★★
描述：
通过对链接追加安全验证码（HMACSHA1）防止跨站请求伪造。通过将正常请求的页面+私钥+用户SessionID进行哈希加密，通过URL传递到操作页面，保证来访页面是指定用户通过指定操作链接来的，从而防止了请求伪造，增加了安全性。
优点：有效防止GET方式的跨站请求伪造。
3．2辅助
【相关文章:】
(动易)给评论内容加上留言本的屏蔽垃圾广告功能
安全上网必备：隐藏私密文件四大方法
电脑使用记录清除技巧大放送
WindowsXP的八大安全策略逐个细解
个人电脑详细的安全设置方法
系统安全小技巧：组策略保障共享目录安全
服务器安全之组件安全
ASP.NET+Win2003虚拟主机多个站点的安全设置
操作系统安全配置
防火墙技术与网络安全
【发表评论】【打印此文】【关闭窗口】【点击数： 】