A-A+

浏览器跨域详解

2019年06月06日 网络安全相关 暂无评论 阅读 73 views 次

背景

最近公司组织了一场网络攻防演练,CSRF(跨站请求伪造攻击),XSS(跨站脚本攻击),SQL注入,cookie拦截修改,各种高大上的名词。最近专注于后台业务,前端知识都变得很模糊,在页面的提示下算是踉踉跄跄做完了。但做完还是一脸懵逼,为什么会存在这些漏洞?这些漏洞的根源在哪里?应对策略是什么?我想把他们全整个明白,特别是CSRF这东西,真的是神奇,就搜了几篇博客,看完又做亲自实验了一下,发现很多博客里并没有提到一个隐藏的比较深的坑,故记录下来供各位兄弟参考。

为什么说专注于后台会导致我对这些东西不甚理解?因为我仔细捋了一下,除了SQL注入是后台直接采用前端参数拼接SQL导致的,其实大部分漏洞都是前端和浏览器导致的。

PS: 其实在我的知识体系里,我是把后台直接与前端打交道的web应用也归为前端应用的。现在大部分网站都是采用前后端分离的架构,也就是所谓的微服务架构(这里不做扩展,有兴趣可以自己研究一下)。我现在手上的项目是分为前,中,后台(严格来说,我所在的部门是一个中台部门,我们只负责对外提供服务接口,从整个公司的层面来看,我所说的前,中,后台整个是一个中台项目)。前台都是一些controller负责分发http请求,中台服务层专注于业务逻辑的实现,一般使用分布式服务框架dubbo,Spring cloud等提供给前端调用。在这样的架构中,前台的controller中的一个个方法就称为一个个微服务。

这样的架构会带来什么问题?

1. 后台的服务接口域名可能和前端H5域名是完全不同的两个域名,那么在H5中访问中台服务接口就会出现跨域问题。

原谅我能想到的问题就这一个(逃~~)。真的是因为,微服务架构带来的利是远远大于弊的,高伸缩性,高可扩展性,高容错性等等等等不是这一篇文章能讲清楚的。

网络域和浏览器同源策略

广义上的域大概是单指一个网站域名,但在专业领域,我们把它叫源,所谓同源是指:

1.协议相同

2.域名相同

3.端口相同

三者同时成立才能叫同源。浏览器的同源策略从它诞生的那一刻就出现了,具体是指:

从域名A下的一个页面(一般是通过ajax请求)获取域名B下的一个资源,是不被浏览器允许的。

这句话需要注意四点:

1. A和B不同源

2. 同源策略是浏览器做的限制

3. 必须得是H5页面中发出的请求,因为是浏览器做的限制,这点也很好理解了,页面是在浏览器中显示,它发出的请求自然是要通过浏览器代为执行的,所以只要你的请求经过了浏览器这一关,是很容易通过浏览器做手脚的。

PS: 所以一开始我想,如果能开发出一个独立的网络请求工具(自己封装和解析http协议),通过脚本直接调用发送网络请求而不经过浏览器,是不是就可以绕过这个限制?但是转念一想,脚本本身就是要通过浏览器来解释执行的啊喂!!!但是又一转念,脚本本身通过浏览器解释执行跟能不能通过脚本调用自己的网络请求工具有矛盾吗?浏览器又不知道我要调用的工具是要发送请求的,除非他能像wireshark那样神通广大拦截所有请求(不过也有它拦截不到的报文,猜猜是发给谁的报文~~),但是这样做是很不讲道理的。哎,越想越多停不下来了,还是打住吧,我又不懂浏览器编程,鬼知道它还会有什么别的稀奇古怪的限制……

4. 不被允许的意思是,浏览器还是会发出这个请求,但是它会拦截响应内容,如果发现响应header中”Access-Control-Allow-Origin”设置的允许访问的源没有包含当前源,则拒绝将数据返回给当前源。(这就是很多博客中没有提到的一个坑)

另:页面中的一些标签是不做同源限制的,比如<img> <script> <style>等标签,这些标签里的src地址可以与当前页不同源

以上文字转载自 http://91o.cc/-很多人没有提到的坑/

标签:

给我留言

您必须 登录 才能发表留言!

Copyright © 软件智博 保留所有权利.   Theme  Ality 鲁ICP备17027378号

用户登录 ⁄ 注册