传统防御技术
2.1.1基于特征的防御
传统XSS防御多采用特征匹配方式,在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击,采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索,一旦发现提交信息中包含“javascript”,就认定为XSS攻击。
2.1.2 基于代码修改的防御
和SQL注入防御一样,XSS攻击也是利用了Web页面的编写疏忽,所以还有一种方法就是从Web应用开发的角度来避免:
1、对所有用户提交内容进行可靠的输入验证,包括对URL、查询关键字、HTTP头、POST数据等,仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交,对其他的一律过滤。
2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查,以防功能被第三方网站所执行。
3、确认接收的的内容被妥善的规范化,仅包含最小的、安全的Tag(没有javascript),去掉任何对远程内容的引用(尤其是样式表和javascript),使用HTTP only的cookie。
当然,如上方法将会降低Web业务系统的可用性,用户仅能输入少量的制定字符,人与系统间的交互被降到极致,仅适用于信息发布型站点。
并且考虑到很少有Web编码人员受过正规的安全培训,很难做到完全避免页面中的XSS漏洞。
扩展资料:
XSS攻击的危害包括
1、盗取各类用户帐号,如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
受攻击事件
新浪微博XSS受攻击事件
2011年6月28日晚,新浪微博出现了一次比较大的XSS攻击事件。
大量用户自动发送诸如:
“郭美美事件的一些未注意到的细节”,“建党大业中穿帮地方”,“让女人心动的100句诗歌”,“这是传说中的神仙眷侣啊”等等微博和私信,并自动关注一位名为hellosamy的用户。
事件的经过线索如下:
20:14,开始有大量带V的认证用户中招转发蠕虫
20:30,某网站中的病毒页面无法访问
20:32,新浪微博中hellosamy用户无法访问
21:02,新浪漏洞修补完毕
百度贴吧xss攻击事件
2014年3月9晚,六安吧等几十个贴吧出现点击推广贴会自动转发等。并且吧友所关注的每个关注的贴吧都会转一遍,病毒循环发帖。并且导致吧务人员,和吧友被封禁。
参考资料:
XSS攻击-百度百科
如果把“需要”替换为“遵守”可能更好一些。
同源策略的本质是一种约定,可以说web的行为就是构建在这种约定之上的。就好比我们人类的行为必须受到法律的约束一样。同源策略的目的就是限制不同源的document或者脚本之间的相互访问,以免造成干扰和混乱。
ajax太灵活了,各种请求说法就发,如果没有同源策略的限制,发到哪里都行,只要你构造好参数和请求路径,那人人都是黑客了,这样会导致各种敏感数据的泄露。
另外呢,那些带src属性的scriptimgiframelink等标签是不需要遵守同源策略的,但是通过src加载的资源,浏览器限制了javascript的权限,不能进行各种的读写。从而,即使请求发了,敏感数据回来了,也是取不到的。
通过上对比,带有src的标签不被同源策略限制,因为javascript本身就做了读写的限制,而ajax本身就是js的,太灵活了,javascript读写方便,所以它必须遵守同源策略。
最后再补充一点,如果ajax非要跨越,可以使用cors。你可以百度“cors 跨域”来学习一下。
没有同源(同协议、同域名、同端口)策略,就天下大乱了。
如果没有同源策略,不同源的数据和资源(如HTTP头、Cookie、DOM、localStorage等)就能相互随意访问,根本没有隐私和安全可言。为了安全起见和资源的有效管理,浏览器当然要采用这种策略。
至于题主说的最后一个“绕开”,我没能理解是什么意思,大概是对同源的概念理解不透彻。
推荐看看cos的《Web前端黑客技术揭秘》,非常系统的解析了前端安全知识,这些知识都是要围绕着同源策略展开的,可想而知它是有多重要。
在前后端分离架构下,难免会遇到跨域问题。但是对于跨域,很多人并没有多么深入的了解。这里我就详细讲一下这个问题。
同源策略与跨域
所谓跨域,英文叫做cross-domain,是网络安全领域的一个专有名词。简单点理解就是某些操作越过了域名的界限,访问了别的域名。
如果脚本可以自由访问其他域,就会产生很多安全问题。
比如,假设有一个网上银行系统,你已经登录过了,它支持一个ajax api可以进行转账;有一个论坛系统,人气很高,但是其中有恶意脚本,这个脚本会调用这个ajax api,从当前登录的用户账户中,转1000块到攻击者的账户。这样,当你访问这个论坛的时候,就会被转走1000块,而你一点都不知道!
除此之外,跨域请求还有很多危害。这不是一本关于安全的书,也就不展开讲了,想深入了解的可以买一本余弦编写的《Web前端黑客技术揭秘》。
为了防范跨域攻击,所有现代浏览器都遵循一套同源策略。根据MDN上的定义,“如果两个页面拥有相同的协议(protocol),端口(如果指定),和主机,那么这两个页面就属于同一个源(origin)”。对于违反同源策略的请求,除了img src等少数嵌入操作之外,都会被浏览器阻止。
这里需要注意的是:同源不仅仅要求相同的域名或ip,连协议和端口也必须相同。比如和或就不是同源的,而和是同源的。
我们平常所说的“跨域”其实就是指“发起不同源请求”,而这样的跨域请求会被浏览器阻止。
同源策略对保障互联网安全有着非常重要的作用,很多安全策略都是基于同源策略的。但是,这种同源策略会对前后端分离架构下的开发过程带来很大困扰。比如,即使是本地服务器,也没法和前端开发服务器运行在同一个端口上,这时候,跨域是必然的。而如果要让后端程序同时提供web服务,则很难发挥前端工具链的轻量级优势。那么,如何解决跨域问题呢?
如何解决跨域问题?
JSONP方式
最初用来解决跨域问题的方式,叫做JSONP,它的基本原理是:跨域的“资源嵌入”是被浏览器允许的。所以,可以通过一个script标签来嵌入一段来自其他服务器的脚本。由于这个脚本完全运行在当前域,无法访问第三方服务器的cookie等敏感信息,所以是安全的。
JSONP的缺点是它只能支持GET操作,没法支持POST等操作,但是由于兼容性好等优点,仍然有很多网站采用JSONP的方式公开自己的API供第三方调用。
在Angular中,$http内置了对JSONP的支持,它的调用接口也和其他方法没什么区别,使用起来非常简单。
反向代理方式
要想解决跨域问题,最简单彻底的方法当然是把他们拉到一个域下,而这就是该“反向代理”发挥作用的时候了。
所谓反向代理,就是在自己的域名下架设一个Web服务器,这个服务器会把请求转发给第三方服务器,然后把结果返回给客户端。
这时候,在客户端看来,自己就是在和这台反向代理服务器打交道,而不知道第三方服务器的存在。
所以,如果有一个Web服务程序,它同时提供了反向代理功能和静态文件服务功能,静态文件服务负责渲染前端页面,反向代理则提供对第三方服务器的透明访问。那么前端和后端就变成了同源的,不再受同源策略的约束。
那么,有这样的Web服务程序吗?有,而且不止一个。事实上,几乎所有的主流Web服务器都提供了反向代理功能。这里仅以nginx为例来示范反向代理的配置方式,其他Web服务器请搜相应的文档自行研究。
server {
listen 80;
server_name your.domain.name;
location / {
proxy_pass ; # 把根路径下的请求转发给前端工具链(如gulp)打开的开发服务器,如果是产品环境,则使用root等指令配置为静态文件服务器
}
location /api/ {
proxy_pass ; # 吧 /api 路径下的请求转发给真正的后端服务器
proxy_set_header Host $http_host; # 把host头传过去,后端服务程序将收到your.domain.name,否则收到的是localhost:8080
proxy_cookie_path /api /service; # 把cookie中的path部分从/api替换成/service
proxy_cookie_domain localhost:8080 your.domain.name; # 把cookie的path部分从localhost:8080替换成your.domain.name
}
}
注意最后这两句话,由于cookie中存在一个path机制,可以对同一个域下的不同子域进行区分。所以,如果后端所使用的路径是/service,而前端使用的路径是/api,那么前端将不能访问后端的cookie,这就导致登录等操作所写入的cookie无法正常传入传出,其表现则是登录始终没有效果。cookie的domain机制也是类似的原理。
现实中的后端服务器,使用path机制的很多,所以这项设置非常实用。
CORS方式
这是W3C提供的另一种跨域方式。作为一项标准的跨域规范,CORS本应该是最值得采用的。 问题在于,老式浏览器不支持CORS,而我们显然还没到可以无视老式浏览器的时候。 所以,只要有可能,就应该优先采用反向代理的方式。
CORS的原理是基于服务方授权的模式,也就是说提供服务的程序要主动通过CORS回应头来声明自己信任哪些源(协议+域名+端口)。 由于得到了服务方的授权,浏览器就可以放行来自这些域的请求了。
参考:
前后台分离,nodeJS转发请求实现跨域访问 :
cument或者脚本之间的相互访问,以免造成干扰和混乱。ajax太灵活了,各种请求说法就发,如果没有同源策略的限制,发到哪里都行,只要你构造好参数和请求路径,那人人都是黑客了,这样会导致各种敏感数据的泄露。另外呢,那些带src属性的scriptimgiframelink等标签是不需要遵守同源