AngularJSXSS攻击的缓解方法

在自己上一篇《前端安全之XSS攻击》文中,并未把XSS攻击的消除办法说完全,而XSS的抨击又那么五花捌门,有未有一招“独孤玖剑”能够比美,终究那么多情况场景,开发职员不只怕一1照顾过来,而明日透过阅读《白帽子讲Web安全》那本书,对应对格局有了越来越好的总括,分为两类,壹是服务端能够干的事,二是客户端能够干的事。

前提

在说XSS化解措施时,有三个前提。就是同源策略——浏览器的同源策略(浏览器安全的底蕴,即便是攻击脚本也要遵循这法则),限制了来自分化源的“document”或脚本,对当前“document”读取或设置有个别品质。除了DOM、Cookie、XMLHttpRequest会受到同源策略的限制外,浏览器加载的1部分第一方插件也有各自的同源策略。然而script、img、iframe、link等标签都得以跨域加载能源,而不受同源策略的界定。

服务端能够干的事

1. HttpOnly

事实上就是当今HTTP协议(HTTPS也是可以的)才能读取cookies,JavaScript是读取不到cookies的。支持浏览器是IE六+、Firefox二+、谷歌(Google)、Safari4+。

JavaEE给Cookie添加HttpOnly的代码:

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

PS:对于HTTPS,照旧得以设置Secure字段,对库克ie进行安全加密。

那是精神上不是预防XSS,而是在被攻陷时候差别意JS读取Cookie。

二.甩卖富文本

稍稍数据因为运用境况难题,并不能够平昔在服务端实行转义存款和储蓄。可是富文本数据语义是完全的HTML代码,在出口时也不会拼凑到有些标签的品质中,所以能够当新鲜情状特殊处理。处理的进程是在服务端配置富文本标签和属性的白名单,差异意出现任何标签或性质(例如script、iframe、form等),即”XSS
Filter“。然后在蕴藏从前开始展览过滤(过滤原理未有去摸清)。

Java有个开源项目Anti-萨姆y是充裕好的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回。

客户端能够干的事

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:当然不止这一个

二. 出口检查

诚如正是在变量输出到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页面时发生。当先5/⑩的MVC框架在模板(view层)会活动处理XSS难点,例如AngularJS。

用什么样编码转义

首要有HTMLEncode和JavaScriptEncode那五个,客户端和服务端都能做。不过让后端去做,我深感是非常的小可相信的,因为数量的行使景况或许有二种,能够在标签、属性、或脚本里(甚至其余终端应用),单单以一种办法去encode是很极限的。

一.HTMLEncode,正是将字符转换到HTMLEntities,一般会转(&、<、>、”、’、/)那5个字符。

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

PS:我在《HtmlEncode和JavaScriptEncode(预防XSS)》一文化总同盟结了比较完好的HTMLEncode和JavaScriptEncode多少个前端函数的写法,以及某个演示。

哪些地点须求编转义

1.在HTML标签、属性中输出——用HTMLEncode

二.在script标签中输出——用JavaScriptEncode

叁.在事变中输出——用JavaScriptEncode

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

4.在CSS中输出

用接近JavaScriptEncode的章程。将除了字母、数字外的有着字符都编码成十陆进制情势”\uHH“。

伍.在地方中输出

诚如只要变量是全体ULacrosseL,则先检查变量是还是不是以“http”起头(不是则扶助添加http),有限支撑不会冒出伪协议类的XSS攻击。然后再对变量实行U帕杰罗LEncode。

PS:U昂科威LEncode会将字符转换来”%HH“形式。

总结

前端开发职员要专注在不利的地点采用科学的编码格局,有时为了防御XSS,在三个地点大家需求壹起HTMLEncode、JavaScriptEncode实行编码,甚至是增大,并不是一定壹种艺术编码(又是具体情形具体分析)。

貌似存款和储蓄型XSS风险高于反射型XSS。反射型XSS一般供给攻击者诱使用户点击贰个包涵XSS代码的U帕杰罗L链接;而存款和储蓄型只必要用户查看1个常规的U奥迪Q5L链接,当用户打开页面时,XSS
Payload就会被实践。那样漏洞极其隐蔽,且隐蔽在用户的健康作业中,危害很高。(引自白帽子讲Web安全原作)

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

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

相关文章