XSS攻击的化解措施

每当本人上平等首《前者安全之XSS攻击》文中,并没把XSS攻击的解决办法说完全,而XSS的攻击还要那么五花八门,有没有出同等造成“独孤九剑”能够媲美,毕竟那多状况场景,开发人员无法一一照顾过来,而今天通过看《白帽子讲Web安全》这本开,对应对术发出矣再也好的下结论,分为两类,一是服务端可以提到的转业,二凡是客户端好提到的事。

前提

于游说XSS解决办法时,有一个前提。就是同源策略——浏览器的同源策略(浏览器安全之根基,即使是攻击脚本也要是遵守就法虽),限制了来自不同源的“document”或脚本,对脚下“document”读取或设置某些性能。除了DOM、Cookie、XMLHttpRequest会受到同源策略的界定外,浏览器加载的片段老三方插件也来各自的同源策略。不过script、img、iframe、link等标签还可以跨域加载资源,而未被同源策略的限。

服务端可以提到的从

1. HttpOnly

实际上就是是现HTTP协议(HTTPS也是好的)才会读取cookies,JavaScript是读取不至cookies的。支持浏览器是IE6+、Firefox2+、Google、Safari4+。

JavaEE给Cookie添加HttpOnly的代码:

response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

PS:对于HTTPS,还是得以安装Secure字段,对Cookie进行安全加密。

顿时是本色上不是提防XSS,而是于让攻破时候不容许JS读取Cookie。

2.处理富文本

稍稍数据以使用状况问题,并无能够一直在劳动端进行转义存储。不过富文本数语义是完好的HTML代码,在输出时为不见面拼凑到某标签的习性被,所以可以当特殊状况特别处理。处理的过程是以服务端配置富文本标签及性的白名单,不容许出现任何标签或者性能(例如script、iframe、form等),即”XSS
Filter“。然后于蕴藏之前开展过滤(过滤原理没有错过摸清)。

Java有只开源项目Anti-Samy是生好的XSS Filter:

Policy ploicy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDao.storeUserProfile(cr.getCleanHTML());

PS:当然为可以于前者显示前过滤,但是本人觉着,让前者人员少开东西好,并且服务端只待改一蹩脚。

客户端可提到的转业

1. 输入检查

输入检查的逻辑,必须在服务器端代码中贯彻(因为用JavaScript做输入检查,很轻受攻击者绕了)。目前Web开发的宽广做法,是又于客户端JavaScript中与服务器代码中落实均等的输入检查。客户端JavaScript的输入检查,可以阻止大部分误操作的正常化用户,从而节省服务资源。

PS:简单说,就是输入检查,服务端和客户端都如举行。

除此以外攻击者可能输入XSS的地方,例如:

1.页面中所有的input框
2.window.location(href、hash等)
3.window.name
4.document.referrer
5.document.cookie
6.localstorage
7.XMLHttpRequest返回的数据

PS:当然不止这些

2. 出口检查

貌似就是是当变量输出到HTML页面时,使用编码或转义的方来防御XSS攻击。XSS的本质就是“HTML注入”,用户的数目为算了HTML代码有来实行,从而混淆了原来的语义,产生了新的语义。

触发XSS的地方

1.document.write
2.xxx.innerHTML=
3.xxx.outerHTML=
4.innerHTML.replace
5.document.attachEvent
6.window.attachEvent
7.document.location.replace
8.document.location.assign

PS:如果用jquery,就是那些append、html、before、after等,其实就算是拼接变量到HTML页面时出。大部分底MVC框架在模板(view层)会自动处理XSS问题,例如AngularJS。

故什么编码转义

重中之重有HTMLEncode和JavaScriptEncode这简单单,客户端以及服务端都能召开。但是给后端去开,我觉得是匪酷仗谱的,因为数量的使状况可能发生几乎种,可以于标签、属性、或下本里(甚至其他终端应用),单单因同一种植方式去encode是深极限的。

1.HTMLEncode,就是拿字符转换成为HTMLEntities,一般会转(&、<、>、”、’、/)这6单字符。

2.JavaScriptEncode,是使用”\“对特殊字符进行转义。

PS:我在《HtmlEncode和JavaScriptEncode(预防XSS)》一和平总结了于完好的HTMLEncode和JavaScriptEncode两单前端函数的写法,以及某些演示。

哪些地方需要编转义

1.当HTML标签、属性被输出——用HTMLEncode

2.以script标签中输出——用JavaScriptEncode

3.每当事件中输出——用JavaScriptEncode

<a href="#" onclick="funcA('$var')">test</a>

4.在CSS中输出

用类似JavaScriptEncode的办法。将除了字母、数字外之所有字符都编码成十六进制形式”\uHH“。

5.每当地点被输出

相似要变量是通URL,则先行检查变量是否以“http”开头(不是则帮忙添加http),保证不见面出现伪协议类的XSS攻击。然后重新指向变量进行URLEncode。

PS:URLEncode会将字符转换成”%HH“形式。

总结

前端开发人员一经专注在是的地方采取科学的编码方式,有时为了防御XSS,在一个地方我们要一起HTMLEncode、JavaScriptEncode进行编码,甚至是外加,并无是一定一种植方式编码(又是具体情况具体分析)。

诚如存储型XSS风险高于反射型XSS。反射型XSS一般要求攻击者诱使用户点击一个富含XSS代码的URL链接;而存储型只待用户查看一个正常的URL链接,当用户打开页面时,XSS
Payload就会吃执行。这样漏洞太隐蔽,且隐蔽在用户之正规工作遭,风险大高。(引自白帽子讲Web安全原文)

本文为本来创文章,转载请保留原出处,方便溯源,如有错误地方,谢谢指正。

正文地址 :http://www.cnblogs.com/lovesong/p/5223989.html

相关文章