WEB安全评测解决方案与代码编写规范北京恒华伟业科技股份有限公司2013年10月目录lXss注入简介21.1—个简单的例子21.2网上的xss讲解32防御xss的七条原则92.1前言92.2原则1:不要在页面中插入任何不可信数据-除非这些数已经据根据下面几个原则讲行了编码102.3原则2:在将不可信数据插入到HTML标签之间时.对这些数据进行HTMLEntity编码112.4原则3:在将不可信数据插入到HTML属性里时.对这些数据进行HTML属性编码122.5原则4:在将不可信数据插入到SCRIPT里时.对这些数据进行SCRIPT编码142.6原则5:在将不可信数据插入到StyieS性里时,对这些数据进行CSS编码162.7原则6:在将不可信数据插入到HTMLURL里时.对这些数据进行URL编码172.8原则7:使用富文本时.使用XSS规则引擎进行编码过滤18项目中防御xss的具体措施213.1在isp中的输出防御213.1.1stu标签输出防御213.1.2Esap标签输出防御213.1.3Jav输出代码防御通过〈%=temp%〉的方式22防御url中的xss代码注入攻击办法23控制通过输入非登录页的url讲入系统功能245.1.1Refer验证过滤器245.1.2window.ope和Iwindow.location.hr特殊处理246系统日志组件的调用
方法
快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载
256.1.方法一:直接调用256.1.2方法二1甬过Annotatio251Xss注入简介1.1一个简单的例子先看下现在frp登录页面的xss注入漏洞先打开系统登录页HYPERLINK"http://192.168.2.99:8080/scmm/"http://192.168.2.99:8080/scmm/然后在系统用户名中文本框中输入1,xss:*/-->'">;密码为1点击登录按钮,则出现如下界面原因是系统验证用户名失败后,重新跳转到login.jsp而login.js中通过${userCode}的方式对userCode变量进行了直接的页面输出,从而执行了不安全的脚本,正确的方式使应当对userCode进行字符编码转换后再进行输出,具体的编码转换输出方式,请参照第三章节再比如在一个博客添加页面blogAdd.js中有一个form表单
Form表单提交后跳转到bloglnfo.jsp如果在js中使用blog.subject如果我在from表单中blog.subje文本框中输入“varmyiframe=document.createEleme“nitf(rame”);myiframe.style.heig”h1t0=0px;”;myiframe.style.wid”t1h0=0px;”myiframe.src”=http://www.baidu.c”o;mdocument.getElementsByTagName(body)[0].appendChild(myiframe);则会成功在你的网站上显示出一个百度的页面,使用类似的代码可以实现网站钓鱼功能例如创建一个支付页面,引诱你把账号和密码输入到钓鱼网站中正确的做法是对用户输入blog.subje文本框中的值进行非法字符过滤后再保存到数据库或者在对blog.subje的字段值进行输出的时候进行字符转换转换方式是将VarblogSubject”=
”;修改为VarblogSubject”=
因为strut的propert标签默认只对输出的值进行html过滤,而不对javaScrii进行过滤1.2网上的xss讲解XSS漏洞概述:XSS(CrossSiteScript)跨站点脚本攻击是一种注射的问
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
,在这种恶意脚本注入否则良性和信任的网站类型。跨站点脚本(XSS)攻击,攻击者使用时,会出现一个网络应用程序发送恶意代码,一般是在浏览器端脚本的形式,向不同的最终用户。这些缺陷,使攻击成功是相当普遍,发生在任何地方从一个Web应用程序使用在输出它没有验证或编码了用户输入。攻击者可以使用XSS的恶意脚本发送到一个毫无戒心的用户。最终用户的浏览有没有办法知道该脚本不应该信任,将执行该脚本。因为它认为该脚本来从一个受信任的源,恶意脚本可以访问任何Cookie,会话令牌,或其他敏感信息的浏览器保留,并与该网站使用。甚至可以重写这些脚本的HTML网页的内容。XSS漏洞历史:XSS(Cross-sitescripting)漏洞最早可以追溯到1996年,那时电子商务才刚刚起步,估计那时候国内很少人会想象到今天出现的几个国内电子商务巨头淘宝、当当、亚马逊(卓越)。XSS的出现“得益”于JavaScript的出现,JavaScript的出现给网页的
设计
领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计
带来了无限惊喜,包括今天风行的AJAX(AsynschronousJavaScriptandXML)。同时,这些元素又无限的扩充了今天的网络安全领域。XSS漏洞攻击特点:XSS跨站漏洞种类多样人:XSS攻击语句可插入到、URL地址参数后面、输入框内、img标签及DIV标签等HTML函数的属人里、Flash的getURL()动作等地方都会触发XSS漏洞。XSS跨站漏洞代码多样人:为了躲避转义HTML特殊字符函数及过滤函数的过滤,XSS跨站的代码使用“/”来代替安字符“””、使用Tab键代替空格、部分语句转找成16进制、添加特殊字符、改变大小写及使用空格等来绕过过滤函数。如果在您的新闻系统发现安全漏洞,如果该漏洞是一个SQL注入漏洞,那么该漏洞就会得到您的网站管理员密码、可以在主机系统上执行shell命令、对数据库添加、删除数据。如果在您的新闻或邮件系统中发现安全漏洞,如果该漏洞是—个XSS跨站漏洞,那么可以构造一些特殊代码,只要你访问的页面包含了构造的特殊代码,您的主机可能就会执行木马程序、执行'***Cookies代码、突然转到一个银行及其它金融类的网站、泄露您的网银及其它账号与密码等。XSS攻击原理:XSS属于被动式的攻击。攻击者先构造一个跨站页面,利用script、
、
hello
v=newActiveXObject("MSXML2.XMLHTTP.3.0");v.open("GET","HYPERLINK"http://xss.honkwin.com:8080/testxss/doadmin.jsp?v=hacked4"http://xss.honkwin.com:8080/testxss/doadmin.jsp?v=hacked4");v.send();alert(v.statusText);以普通用户身份修改uservalue为以上任何一个,当admin浏览index.jsp时,即可悄无声息的修改adminvalue这里演示了3种跨站手法:1是利用img、iframe等tag直接发起请求,这适用于无法直接出script的情况,其中HYPERLINK"http://bbs.honkwin.com/2xwfed"http://bbs.honkwin.com/2xwfed是一个redirect,扌指向HYPERLINK"http://xss.honkwin.com:8080/testxss/doadmin.jsp?v=hacked2"http://xss.honkwin.com:8080/testxss/doadmin.jsp?v=hacked2;2是用script提交post表单;3是ajax技术。以上攻击能够成功有2个原因:应用程序没有对uservalue做足够多的过滤,导致用户有机会构造一个复杂的跨站语句来触发admin的非预期行为;应用程序在响应adminvalue修改请求时没有防范措施来识别这是不是出于用户主动。漏洞1很容易修复,只要像防止SQLInjection那样对用户输入的所有内容都过滤即可。漏洞2才是问题的根源,即便我们修补了漏洞1,只要诱使admin用户访问包含〈imgsrc二"http://bbs.honkwin.com/2xwfed">的页面,仍然能达到目的,而这是一件极容易做到的事。防范措施:这里给出一些防范XSS攻击的措施。必须说明的是,对于XSS攻击,并不像SQLInjection那样可以有一劳永逸的解决方案只需要grep—下所有的sql调用。这是一场长期的斗争,而且往往需要我们采取修改业务流程、产品设计等看似削足适履的手段。先总结一下常见的攻击手法:依赖跨站漏洞,需要在被攻击网站的页面种入脚本的手法Cookie盗取,通过javascript获取被攻击网站种下的cookie,并发送给攻击者。从cookie中提取密码等隐私利用cookie伪造session,发起重放攻击Ajex信息盗取,通过javascript发起ajex请求。从ajex结果中获取隐私。模拟用户完成多页表单。不依赖跨站漏洞的手法单向HTTP动作,通过img.src等方法发起跨站访问,冒充被攻击者执行特权操作。但是很难拿到服务器的返回值。双向HTTP动作,如果服务器产生一段动态的script,那么可以用script.src的方法发起跨站访问并拿到服务器的返回值。防范手法如下:防堵跨站漏洞,阻止攻击者利用在被攻击网站上发布跨站攻击语句不可以信任用户提交的任何内容,首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”'”等字符做过滤;其次任何内容写到页面之前都必须加以encode,避免不小心把htmltag弄出来。这一个层面做好,至少可以堵住超过一半的XSS攻击。Cookie防盗首先避免直接在cookie中泄露用户隐私,例如email、密码等等。其次通过使cookie和系统ip绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值,不可能拿来重放。尽量采用POST而非GET提交表单POST操作不可能绕开javascript的使用,这会给攻击者增加难度,减少可利用的跨站漏洞。严格检查refer检查httprefer是否来自预料中的url。这可以阻止第2类攻击手法发起的http请求,也能防止大部分第1类攻击手法,除非正好在特权操作的引用页上种了跨站访问。将单步流程改为多步,在多步流程中引入效验码多步流程中每一步都产生一个验证码作为hidden表单元素嵌在中间页面,下一步操作时这个验证码被提交到服务器,服务器检查这个验证码是否匹配。首先这为第1类攻击者大大增加了麻烦。其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求,这在第2类攻击中是几乎无法做到的。引入用户交互简单的一个看图识数可以堵住几乎所有的非预期特权操作。只在允许anonymous访问的地方使用动态的javascript。对于用户提交信息的中的img等link,检查是否有重定向回本站、不是真的图片等可疑操作。内部管理网站的问题很多时候,内部管理网站往往疏于关注安全问题,只是简单的限制访问来源。这种网站往往对XSS攻击毫无抵抗力,需要多加注意。安全问题需要长期的关注,从来不是一锤子买卖oXSS攻击相对其他攻击手段更加隐蔽和多变,和业务流程、代码实现都有关系,不存在什么一劳永逸的解决方案。此外,面对XSS,往往要牺牲产品的便利性才能保证完全的安全,如何在安全和便利之间平衡也是一件需要考虑的事情。web应用开发者注意事项:1.对于开发者,首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。2•保护所有敏感的功能,以防被bots自动化或者被第三方网站所执行。实现session标记(sessiontokens)、CAPTCHA系统或者HTTP引用头检查。如果你的web应用必须支持用户提供的HTML,那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点:确认你接收的HTML内容被妥善地格式化,仅包含最小化的、安全的tag(绝对没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript)。为了更多的安全,请使用httpOnly的cookie。2防御xss的七条原则2.1前言本章节将会着重介绍防御XSS攻击的一些原则,需要读者对于XSS有所了解,至少知道XSS漏洞的基本原理,如果您对此不是特别清楚,请参考这两篇文章:《StoredandReflectedXSSAt》《(DOMBasedXSS》攻击者可以利用XSS漏洞向用户发送攻击脚本,而用户的浏览器因为没有办法知道这段脚本是不可信的,所以依然会执行它。对于浏览器而言,它认为这段脚本是来自可以信任的服务器的,所以脚本可以光明正大地访问Cookie,或者保存在浏览器里被当前网站所用的敏感信息,甚至可以知道用户电脑安装了哪些软件。这些脚本还可以改写HTML页面,进行钓鱼攻击。虽然产生XSS漏洞的原因各种各样,对于漏洞的利用也是花样百出,但是如果我们遵循本文提到防御原则,我们依然可以做到防止XSS攻击的发生。有人可能会问,防御XSS的核心不就是在输出不可信数据的时候进行编码,而现如今流行的Web框架(比如RailS大多都在默认情况下就对不可信数据进行了HTML编码,帮我们做了防御,还用得着我们自己再花时间研究如何防御XSS吗?答案是肯定的,对于将要放置到HTML页面body里的不可信数据,进行HTML编码已经足够防御XSS攻击了,甚至将HTML编码后的数据放到HTML标签(TAG)的属性(attribu)e里也不会产生XSS漏洞(但前提是这些属性都正确使用了引号),但是,如果你将HTML编码后的数据放到了〈SCRIPT>标签里的任何地方,甚至是HTML标签的事件处理属性里(如onmouseover),又或者是放到了CSS、URL里,XSS攻击依然会发生,在这种情况下,HTML编码不起作用了。所以就算你到处使用了HTML编码,XSS漏洞依然可能存在。下面这几条规则就将告诉你,如何在正确的地方使用正确的编码来消除XSS漏洞。2.2原则1:不要在页面中插入任何不可信数据,除非这些数已经据根据下面几个原则进行了编码第一条原则其实是“SecureByDefau”原则:不要往HTML页面中插入任何不可信数据,除非这些数据已经根据下面几条原则进行了编码。之所以有这样一条原则存在,是因为HTML里有太多的地方容易形成XSS漏洞,而且形成漏洞的原因又有差别,比如有些漏洞发生在HTML标签里,有些发生在HTML标签的属性里,还有的发生在页面的〈Script里,甚至有些还出现在CSS里,再加上不同的浏览器对页面的解析或多或少有些不同,使得有些漏洞只在特定浏览器里才会产生。如果想要通过XSS过滤器(XSSFilt)对不可信数据进行转义或替换,那么XSS过滤器的过滤规则将会变得异常复杂,难以维护而且会有被绕过的风险。所以实在想不出有什么理由要直接往HTML页面里插入不可信数据,就算是有XSS过滤器帮你做过滤,产生XSS漏洞的风险还是很高。〈script不要在这里直接插入不可信数据〈/scrip直接插入到SCRIPT标签里插入到HTML注释里〈div不要在这里直接插入不可信数据=””>插入到HTML标签的属性名里〈divname=”不要在这里直接插入不可信数据”>〈/div>插入到HTML标签的属性值里>〈/a>〈不要在这里直接插入不可信数据href=””作为HTML标签的名字〈style不要在这里直接插入不可信数据直接插入到CSS里最重要的是,千万不要引入任何不可信的第三方JavaScrip到页面里,—旦引入了,这些脚本就能够操纵你的HTML页面,窃取敏感信息或者发起钓鱼攻击等等。2.3原则2:在将不可信数据插入到HTML标签之间时,对这些数据进行HTMLEntity编码在这里相当强调是往HTML标签之间插入不可信数据,以区别于往HTML标签属性部分插入不可信数据,因为这两者需要进行不同类型的编码。当你确实需要往HTML标签之间插入不可信数据的时候,首先要做的就是对不可信数据进行HTMLEntity编码。比如,我们经常需要往DIV,P,TD这些标签里放入—些用户提交的数据,这些数据是不可信的,需要对它们进行HTMLEntity编码。很多Web框架都提供了HTMLEntity编码的函数,我们只需要调用这些函数就好,而有些Web框架似乎更“智能”比如Rails它能在默认情况下对所有插入到HTML页面的数据进行HTMLEntity编码,尽管不能完全防御XSS,但着实减轻了开发人员的负担。〈body〉插入不可信数据前,对其进行HTMLEntity编码〈/body>〈div>插入不可信数据前,对其进〈/div>〈p)插入不可信数据前,对其进行HTMLEntity编码以此类推,往其他HTML标签之间插入不可信数据前,对其进行HTMLEntity编码[编码规则]那么HTMLEntity编码具体应该做哪些事情呢?它需要对下面这6个特殊字符进行编码:&->&〈-><>->>”->"‘->'/->/有两点需要特别说明的是:不推荐将单引号(‘)编码为&apos;因为它并不是标准的HTML标签需要对斜杠号(/编码,因为在进行XSS攻击时,斜杠号对于关闭当前HTML标签非常有用推荐使用OWASP提供的ESAPI函数库,它提供了一系列非常严格的用于进行各种安全编码的函数。在当前这个例子里,你可以使用:StringencodedContent=ESAPI.encoder().encodeForHTML(request.getPar“amientpeurt”());2.4原则3:在将不可信数据插入到HTML属性里时,对这些数据进行HTML属性编码这条原则是指,当你要往HTML属性(例如width、name、value属性)的值部分(datavalU粛入不可信数据的时候,应该对数据进行HTML属性编码。不过需要注意的是,当要往HTML标签的事件处理属性(例如onmouseover)里插入数据的时候,本条原则不适用,应该用下面介绍的原则4对其进行JavaScript码。〈divatt插入不可信数据前,进行HTML属性编码>〈/div>g性值部分没有使用引号,不推荐〈divatt'插入不可信数据前,进行HTML属性编码'>