点晴MIS内部交流论坛加入收藏
新手上路
论坛搜索
 您的位置:点晴MIS系统问题答疑『 经验分享&问题答疑 』浏览当前帖子  
登 陆注 册论坛帮助  

  网站搜索
  搜索范围: 搜索方式: 关键词(可用空格分开)  

  作者及文章信息: 本文热度:123 % 
admin

积分:77829
等级:网站管理员
文数:10819
注册:2004-7-20

  信 息   留 言   主 页   编 辑   引 用    

楼 顶 

 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

  离 线  2020/4/8 15:04:50 
  本文章共有 0 页, 0 张回文,每页有 10 张回文 >> [ ]
页码:
Copyright 2003-2020 ClickSun All Rights Reserved