同源策略拦截,为什么黑客不能同源策略

hacker2022-10-10黑客177

如何正确防御xss攻击

传统防御技术

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攻击-百度百科

ajax 为什么需要 同源策略

如果把“需要”替换为“遵守”可能更好一些。

同源策略的本质是一种约定,可以说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转发请求实现跨域访问 :

评论列表

访客
访客
2022-10-10

cument或者脚本之间的相互访问,以免造成干扰和混乱。ajax太灵活了,各种请求说法就发,如果没有同源策略的限制,发到哪里都行,只要你构造好参数和请求路径,那人人都是黑客了,这样会导致各种敏感数据的泄露。另外呢,那些带src属性的scriptimgiframelink等标签是不需要遵守同源

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。