《系统安全培训-Web安全性.ppt》由会员分享，可在线阅读，更多相关《系统安全培训-Web安全性.ppt（37页珍藏版）》请在三一文库上搜索。
1、系统安全 Web安全性,2010年9月,2009中国计算机网络安全应急年会资料,安全性问题之一SQL注入,什么是 SQL Injection: (SQL注入) 就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。 简而言之，是在输入的数据字符串中夹带SQL指令，在设计不良的程序中忽略了检查，那么在这些夹带的指令就会被数据库服务器误认为是正常的SQL指令而运行，因此招致到破坏,安全性问题之一SQL注入,SQL Injection: (SQL注入) SQL注入是最常见的攻击方式，它的主要原理是：攻击者通过改变WEB页的参数，直接将SQL片断提交到服
2、务器，并在服务器端执行的过程。,安全性问题之一SQL注入,SQL注入的原因 1、在应用程序中使用字符串联结方式组合SQL指令 2、在应用程序链接数据库时使用权限过大的帐号（例如使用SA） 3、在数据库中开放了不必要但权力过大的功能（如，在SQLServer中的的xp_cmdshell延伸预存程序或是OLE Automation预存程序等） 4、太过于信任用户所输入的数据，未限制输入的字符数,安全性问题之一SQL注入,SQL注入的危害 修改数据库内容 删除其它表 窃取数据到本地 执行系统命令，进而修改或控制操作系统、破坏硬盘数据等 特点 攻击耗时少、危害大,安全性问题之一SQL注入,问题代码（A
3、SP+MS SQL Server）,if Request.QueryString(“id“) is NoThing then id=1 else id=Request.QueryString(“id“) end if sql=“select title,content from news where id=“&id set rs=Server.CreateObject(“adodb.Recordset“) rs.Open sql,connection,1,1,安全性问题之一SQL注入,修改数据库内容 提交语句http:/localhost/news.asp?id=1;update news s
4、et title=test where title=oldtitle 执行语句：select title,content from news where id=1;update news set title=test where title=oldtitle,安全性问题之一SQL注入,删除其它表 提交语句http:/localhost/news.asp?id=1;drop table tablename 执行语句：select title,content from news where id=1;drop table tablename,服务器返回的错误信息,关键文件路径,服务器返回的错误信息
5、,如何预防SQL注入?,从应用程序的角度来讲,我们要做以下三项工作: 1. 转义敏感字符及字符串(SQL的敏感字符包括: “exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”/”,”,”;”,”,”-”,”%”,”0x”,”=!-*/()|”,和”空格”)。 2. 屏蔽出错信息：阻止攻击者知道攻击的结果 3. 服务端正式处理之前对提交数据的合法性进行检查(包括：数据类型,数据长度,敏感字符的校验) 。在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作。,如何预防SQL注入?,从实际应用还需要注意： 1. 只要是提交的数据包含非法字符，或者要替
6、换为安全字符，或者提交的数据要替换为默认值。 2. 含有非法字符串的数据提交不应该显示“您所提交的数据非法”等类似的提示。因为对于访问者而言，这是没有必要的。 3. 尽可能完善操作日志记录和错误日记记录。,安全性问题之二上传文件漏洞,伪造客户端绕过上传后缀名检查 可能导致上传木马 解决方法：使用白名单，后台检查,防止木马执行的方法,给各个不必要的目录，去掉“执行”权限;删除不需要的程序映射。,安全性问题之三XSS,Cross-Site Scripting (XSS):(跨站点脚本攻击) XSS是由于Web程序没有对用户提交的HTML内容进行适当的过滤，这样攻击者就可能在你的Web页中插入一些H
7、TML语句，这些语句通过以标签的形式出现。 攻击者通常使用跨站脚本攻击来窃取COOKIES 和 SESSION信息，或是欺骗用户将隐私信息暴露给错误对象(又称为钓鱼) 。,问题三XSS, Results for window.open(http:/? . document.cookie .) ,Attack Server,受害人服务器,受害人客户端,user gets bad link,user clicks on link,victim echoes user input,http:/ ? term = . ,,,安全性问题之三XSS,跨站脚本XSS利用示例 Cookie、Session 会
8、话Cookie ASPSESSIONIDXXXXXXXX、JSESSIONID、PHPSESSID,安全性问题之三XSS,在html编辑输入：显示cookie,安全性问题之四SCRF,Cross-Site Request Forgery (SCRF):(跨站点请求伪造) SCRF的特性就是利用网站对用户标识的信任，欺骗用户的浏览器发送HTTP请求给目标站点。,安全性问题之四SCRF,浏览器和网站建立认证的会话,Web浏览器跟可信的站点建立了一个经认证的会话之后，只要是通过该Web浏览器这个认证的会话所发送的请求，都被视为可信的动作。,安全性问题之四SCRF,浏览器发送有效的请求,浏览器正在发送
9、一个有效的请求，即Web浏览器企图执行一个可信的动作。可信的站点经确认发现，该Web浏览器已通过认证，所以该动作将被执行。,安全性问题之四SCRF,恶意站点伪造的有效请求,图中，发生了一个SCRF攻击。发起攻击的站点致使浏览器向可信的站点发送一个请求。该可信的站点认为，来自该Web浏览器的请求都是经过认证的有效请求，所以执行这个“可信的动作”。SCRF攻击之所以会发生，其根本原因就是Web站点所验证的是Web浏览器而非用户本身。,安全性问题之四SCRF,假如张三在浏览目标站点A，那么站点A便会给张三的浏览器一个cookie，用于存放一个伪随机数作为会话标识符sid，以跟踪她的会话。该站点会要求
10、张三进行登录，当她输入有效的用户名和口令时，该站点会记录这样一个事实：张三已经登录到会话sid。当张三发送一个请求到站点A时，她的浏览器就会自动地发送包含sid的会话cookie。之后，站点A就会使用站点的会话记录来识别该会话是否来自张三。,安全性问题之四SCRF,现在，我们假设张三访问了一个恶意站点B，该站点提供的内容中的JavaScript代码或者图像标签会导致张三的浏览器向站点A发送一个HTTP请求。由于该请求是发给站点A的，所以张三的浏览器自动地给该请求附上与站点A对应的该会话cookie的sid。站点A看到该请求时，它就能通过该cookie的推断出：该请求来自张三，所以站点A就会对张
11、三的帐户执行所请求的操作。这样，SCRF攻击就能得逞了。,安全性问题之四SCRF,客户端 (认证)服务器 Cookie: sid 第三方站点客户端 (恶意命令请求)服务器 第三方站点内容： 指令：张三的账户A向账号B转账，交易金额1000,安全性问题之四SCRF,总之，只要身份认证是隐式进行的，就会存在SCRF攻击的危险，因为浏览器发出请求这一动作未必是受用户的指使。 原则上，这种威胁可以通过对每个发送至该站点的请求都要求用户进行显式的、不可欺骗的动作(比如重新输入用户名和口令)来消除，但实际上这会导致严重的易用性问题。 大部分标准和广泛应用的认证机制都无法防止CSRF攻击。,安全性问题之四S
12、CRF,SCRF成功发动攻击前提是，用户必须已经登录到目标站点，并且必须浏览了攻击者的站点或被攻击者部分控制的站点。,安全性问题之四SCRF,SCRF和XSS攻击的区别在于，XSS攻击需要JavaScript，而CSRF攻击不需要；XSS攻击要求站点接受恶意代码，而对于SCRF攻击来说，恶意代码位于第三方站点上。 防御XSS攻击的措施无法保护站点不受SCRF攻击的危害。如果站点具有XSS攻击漏洞，那么它也有SCRF攻击漏洞。但是，即使站点针对XSS攻击采取了全面保护，却仍然面临SCRF攻击的威胁。,安全性问题之五XSIO,Cross Site Image Overlaying (XSIO) :
13、跨站图像叠加 XSIO是因为没有限制图片的position属性为absolute，导致可以控制一张图片出现在网页的任意位置。 那么我们就可以用这张图片去覆盖网页上的任意一个位置（link、button）。 这就可以导致页面破坏。而给图片设置一个链接后，很显然就可以起到一个钓鱼的作用。 由于对正常的HTML 标签是没有做过滤的，所以我们可以用这些标签或CSS样式来实施XSIO攻击。,安全性问题之六XSIO,Cross Site Image Overlaying (XSIO) :跨站图像叠加 测试方法: ,安全性问题之六XSIO,http:/XX.XXX.X.XXX/XX_bbs/websourc
14、e/BBS/article_det.aspx?id=15&aid=2015,跨站图像叠加,安全性问题的根源,客户端数据的不可信任性。 Never under any circumstances trust data from the browser.（从不要相信来自浏览器端的数据，因为你永远不可能知道在浏览器进行数据操作是你的用户还是正在寻找攻击漏洞的黑客） 不信任客户端如何交换数据？,解决方法：安全性测试,安全性测试是一个很大的题目，首先取决于要达到怎样的安全程度。不要期望网站可以达到100%的安全。,解决方法：安全性测试,(1)如何进行XSS测试? 首先,找到带有参数传递的URL,如登录页
15、面,搜索页面,提交评论,发表留言页面等等。 其次,在页面参数中输入如下语句(如:Javascript,VB script, HTML,ActiveX, Flash)来进行测试：alert(document.cookie),解决方法：安全性测试,(2)如何预防XSS漏洞? 从应用程序的角度来讲,要进行以下几项预防: 对Javascript,VBscript, HTML,ActiveX, Flash等语句或脚本进行转义。 在服务端正式处理之前对提交数据的合法性进行检查(包括:数据类型,数据长度,敏感字符的校验) 等。 从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查: 在需求检查过程中对各输入项或输出项进行类型、长度以及取值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。 执行测试过程中也应对上述项进行检查。,解决方法：安全性测试,一般实现业务的网站期望的安全指标： 1、能够对密码试探工具进行防范； 2、能够防范对cookie攻击等常用攻击手段； 3、敏感数据保证不用明文传输； 4、能防范通过文件名猜测和查看HTML文件内容获取重要信息； 5、能保证在网站受到攻击后在给定时间内恢复。,