深入理解Same-Origin安全机制
概述
浏览器普遍使用origin来表示权限范围。通过隔离不同origin的内容来防止某些恶意网站的运营人员(黑客)干涉正常网站的运行。本文除了描述构成origin概念的几个核心准则外,还描述了如何确定URI的origin、如何把origin序列化成字符串。本文也定义了一个命名为"Origin"的HTTP头部字段,用来表示与当前HTTP请求相关的origin。
介绍
浏览器解析执行来自不同网站的网页内容,尽管很多网页开发者怀有善意,但是还有一部分可能怀有恶意。浏览器实现方希望能够保护正常网站的安全性不受其他恶意网站的影响。
浏览器加载并渲染来自服务器的HTML文档时会执行包含在这些文档中的脚本程序,浏览器希望阻止恶意脚本读取其他服务器的文档内容。
浏览器根据origin把内容划分成不同的部分,同一个origin的内容之间可以随意交互,但是不同origin之间交互会受到某些限制。
本文档描述了same-origin机制的几个核心准则,同时也对比较和序列化origin做了详细介绍。本文档不会对same-origin的每个方面都进行介绍,细节方面的介绍交由具体的协议文档,比如HTML和WebSockets。
Same-Origin的准则
浏览器按照服务器的网页内容执行相应的动作,比如网页重定向,为脚本提供文档Dom接口。
如果没有任何安全模型的话,浏览器可能会执行对用户有危害的某些行为。随着时间的推移,web技术慢慢地形成了一个称为“same-origin”的网络安全模型。尽管这个安全模型现在进化成很复杂的技术,但是我们可以通过几个核心概念来理解这个模型。这个章节描述了这些核心概念,并且给出了几个如何安全使用这些概念的建议。
信任(Trust)
Same-origin机制通过URI地址来决定是否信任。比如HTML文档通过URI指定运行哪些脚本,< script src=“https://example.com/library.js”>< /script >。当浏览器执行到这个HTML元素的时候,会从URI指定的地址下载js脚本,然后为脚本赋予和当前文档相同的权限。文档通过这种方式把自己所拥有的权限赋予URI指定的资源,也就是说文档相信URI指定的资源。
除了通过URI引用类库外,浏览器也会向URI指定的服务器发送信息,比如HTML表单提交:
<form method="POST" action="https://example.com/login">... <input type="password"> ...</form>
当用户输入用户名和密码之后点击提交,浏览器就会把信息发送到表单URI指定的服务器,这就表明文档的编写者信任URI指定的服务器。
注意(Pitfalls)
当使用Same-origin机制设计新协议的时候,不同的信任对象一定要在URI中体现出来,如果http即表示使用tls安全加密传输也表示不使用tls安全加密传输,那么当文档期望使用tls加密传输的时候,就没办法通过URI指定。所以,通过https表示安全加密传输之后,文档就可以指定只信任https传输的资源文件,这样可以防止黑客攻击。
来源(Origin)
原则上,浏览器认定不同的URI为不同的资源,不同的资源相互通讯需要有明确的许可。这样会为开发增加很多复杂度,因为一个网页应用会包含很多不同的URI。
现在浏览器普遍地把这些不同的URI按照规则划分为不同的组,每个组都称为origin。简单地讲,如果两个URI如果有相同的scheme、host和port就算是属于同一个origin(组)。
提问:为什么不直接使用host当作划分组的依据?
在origin元组中包含scheme是确保网络安全的前提。如果浏览器不包括sheme,那么http://example.com 和 https://example.com之间就没有任何资源隔离。如果没有这层隔离的话,网络黑客可以通过修改来自http://example.com 网站的内容,然后通过修改后的文档控制浏览器去获取 https://example.com中 的内容,从而可以绕过网站设置的TLS(RFC5246)安全层。
提问:为什么使用主机的全限定主机名(portal.ibm.com),而不只是使用顶级域名?
比如教育相关的网站,学生会把相关信息放在 https://example.edu/~student/ ,但是这并不意味着,这个地址内的内容会和位于 https://grades.example.edu/ 的管理年级信息的网页应用拥有相同的权限。这个例子说明了,很多网站在部署的时候都没有按照相关应用场景合理地规划主机域名,所有的学生信息管理应用都使用相同的权限显然不是很合理。所以Origin的分组粒度规划就是网络安全模型的发展史。
几个简单例子
如下几个网站拥有相同的origin:
http://example.com/
http://example.com:80/
http://example.com/path/file
每一个网站都拥有相同的scheme、host、和port。
下面每两个地址都不是相同的origin:
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
授权(Authority)
尽管浏览器把多个URI划分为同一个origin,但是并不是一个origin里的所有资源都拥有相同的权限。比如图片是一个被动获取的资源,它没有与origin中其他资源相同的权限。相反,HTML文档拥有origin的所有权限,并且文档中的脚本可以访问所属origin中的其他资源。
浏览器通过检查资源的媒体类型(media type)来决定授予资源多少权限。当处理用户生成的网页内容时,网络应用可以通过设置媒体类型来限制内容的权限。比如image/png类型的内容就比text/html类型的内容安全的多。很多网页应用在它们的HTML文档中包含了很多不可信的内容,如果处理不当,这些应用可能会把自己的权限暴露给这些不可信的内容,xss(cross-site scripting)就是利用了这种漏洞。
注意(Pitfalls)
在为网络平台设计新功能时,必须谨慎地考虑媒体类型的权限问题。很多网络应用在处理不可靠内容时,一般都会为它们设置不同的媒体类型来限制权限。新功能如果为不可靠的内容授予过高权限可能会为当前的应用架构带来很多安全漏洞。授予权限时,应该把权限授予已经拥有所有权限的某些媒体类型,或者创建一个专门用来表示某些权限的媒体类型。
为了与那些实现媒体类型不正确的服务器做兼容,浏览器使用“content sniffing”[SNIFF]表示与服务器提供的媒体类型不一样的类型。如果处理不当,浏览器很有可能会为低权限的资源(image)授予很高的权限(HTML文档)。
机制(Policy)
通常来说,浏览器通过origin隔离不同的资源,并且允许不同origin的资源可以进行一些受限制的通讯。具体浏览器如何隔离以及如果提供通讯功能取决于几个要素。
对象访问(Object Access)
浏览器通常只给属于同一个origin的资源提供相应的访问接口,更详细的讲,如果两个资源的scheme、host和port都一样,那么它们之间就可以互相访问。
也有一些例外,比如一些HTML location接口可以访问其他origin的内容,HTML的postMessage接口也可以跨origin访问。把当前的接口暴露其他origin非常危险,因为这样可能会导致潜在的网络攻击。
网络访问(Network Access)
往往会根据是否同属于一个origin来决定是否可以访问网络资源。
通常来讲,读取其他origin的网络内容是被禁止的。但是,一个origin内的资源是可以读取其他origin中的某些类型资源。比如在某个origin中是可以执行其他origin中的脚本,渲染图片,以及加载样式表(css)。
同样的,一个origin中可以通过frame来展示其他origin的HTML内容。网络资源可以自由选择是否允许其他origin的服务读取自己的内容,比如通过CORS方式。在这些场景中,这种访问控制基本上是基于单个origin进行授权访问。
向其他origin的服务发送信息是可以的,但是在网络上发送任意格式的数据是比较危险的。基于这个原因,浏览器一般会限制脚本以一定的格式发送信息,比如没有自定义头部的HTTP请求。必须谨慎地增加新的网络协议,比如增加WebSockets支持时不能引入其他网络漏洞。
注意(Pitfalls)
当浏览器允许一个origin中的资源与另一个origin的资源进行交互时会引入新的安全问题。比如展示来自另一个origin的图片时,可能会暴露自己的宽度和高度。从一个origin向另一个origin发送网络请求时可能会引起CSRF攻击。当然,浏览器提供商通常会在跨origin通讯带来的优势与弊端之间权衡。比如浏览器可以通过阻止跨origin访问,禁止用户在本网站中点击其他网站的超链接。
为一种资源添加某个权限同时防止origin中的其他资源拥有这个权限会非常有意思,但是这种授权机制基本上不会生效,因为浏览器是按照origin来进行资源隔离,同一个origin的资源会持有相同的权限。
结论(Conclusion)
Same-origin通过URI来确定信任关系。多个URI组成一个origin,从而形成一个保护域。Origin中的主动资源(active content,比如js)会授予Origin中的所有权限,其他的被动资源(passive content,比如img、css)不会授予这些权限。
URI中的Origin(Origin of a URI)
通过如下算法可以确定一个URI的Origin:
- 如果URI不是层次结构的,或者不是一个绝对地址,那么生成一个全局唯一的标识符。
- 每次运行这个算法都会为同一个URI生成不同的值,所以浏览器会缓存一个HTML文档的Origin值,之后的权限检测会使用第一次计算的Origin。
- 获取URI中的scheme值(比如http、https、file)作为Origin的uri-scheme,并且转换成小写。
- 如果浏览器不支持uri-scheme中指定的协议,那么生成一个全局唯一的标识符。
- 如果uri-scheme是file,那么不同的浏览器实现可能有不同的返回值。
- 历史上,浏览器会为uri-scheme为file的内容授予很高的权限。为本地文件授予这么高的权限可能会遭受特权提升攻击。某些浏览器会为本地文件授权目录级别的权限,但是目前这个方案没有被广泛的采用。目前很多浏览器会为每个本地文件生成一个不同的全局唯一的标识符,这也是目前最安全的措施。
- 获取URI中的host值并赋予uri-host,并且转换成小写。
- 本文档假设浏览器在构建URI时使用IDNA(Internationalizing Domain Names in Applications)规则。并且假定uri-host的值只包含LDH字符,因为浏览器会把non-ASCII的字符转换成A-labels。基于这个原因,origin-based安全机制对浏览器使用的IDNA算法比较敏感。
- 获取uri-port:
- 如果URI没有指定端口,使用uri-scheme指定协议的默认端口。
- 否则使用URI的端口。
- 返回(uri-scheme, uri-host, uri-port)三元组。
比较Origin(Comparing Origins)
只有符合如下规则才会认为两个Origin是相等的:
- 如果两个Origin都是scheme/host/port三元组,那么三元组对应的值都相等,才会认为相同。
- 三元组和唯一标识符永远不相等。
某个URI与自己并不一定属于同一个origin。比如uri-scheme为data的URI,因为“data:”并不使用server-based naming授权机制。
序列化Origin(Serializing Origins)
本章节介绍如何把Origin序列化成unicode字符串和ASCII字符串。
序列化成Unicode字符
下面算法描述了如何把Origin转换成Unicode字符:
- 如果Origin不是scheme/host/port三元组,返回null(U+006E, U+0075, U+006C, U+006C)。
- 如果是scheme/host/port三元组,返回scheme。
- 拼接“: //”。
- 把host的每个部分使用U+002E(“.”)分隔。
- 如果host值使用A-label,那么转换成对应的U-label。
- 否则,一字不差的返回。
- 如果scheme/host/port三元组中port不是scheme指定协议的默认端口,那么:
- 追加U+003A(“:”),把端口号转换成十进制拼接在冒号后面。
- 返回拼接的字符串。
序列化成ASCII字符
下面算法描述了如何把Origin转换成ASCII字符:
- 如果Origin不是scheme/host/port三元组,返回null(U+006E, U+0075, U+006C, U+006C)。
- 如果是scheme/host/port三元组,返回scheme。
- 拼接“: //”。
- 拼接scheme/host/port三元组中的host。
- 如果scheme/host/port三元组中port不是scheme指定协议的默认端口,那么:
- 追加U+003A(“:”),把端口号转换成十进制拼接在冒号后面。
- 返回拼接的字符串。
HTTP中的Origin头部字段
这个章节定义了HTTP协议中的Origin头部字段
语法
origin = "Origin:" OWS origin-list-or-null OWSorigin-list-or-null = %x6E %x75 %x6C %x6C / origin-listorigin-list = serialized-origin *( SP serialized-origin )serialized-origin = scheme "://" host [ ":" port ]; <scheme>, <host>, <port> from RFC 3986
语义(Semantics)
当脚本向服务器发送HTTP请求的时候,浏览器会使用Origin字段用来表明脚本是从哪个站点下载的,可以使得服务器来判断是否接收这个HTTP请求。在某些场景中,可能Origin的值有多个,比如,最初的一个origin发起了HTTP请求,然后转发到另一个origin,那么可以通过Origin字段向服务器表明HTTP请求涉及到两个origin地址。
浏览器要求(User Agent Requirements)
浏览器可能在每一个HTTP请求都会包含Origin头部字段。
浏览器不能在一个HTTP请求中包含多个Origin头部字段。
当浏览器工作在比较隐私的场景下,Origin的字段值必须为“null”。
文档不规定隐私场景的具体含义,应用程序(不指浏览器)可以根据需要规定什么场景下发送的HTTP请求中的Origin字段值为“null”。
当生成Origin字段时,浏览器必须符合如下两个要求:
- origin的值必须是ascii序列化的。
- 两个origin不能是一样的。
安全性考虑(Security Considerations)
Same-origin是很多用户代理,包括浏览器,安全性的基础。用户代理一直在尝试使用其他安全机制,包括污点跟踪(taint tracking)和泄漏保护(exfiltration prevention),但是这些方式很难实现。
评估same-origin的安全性比较困难,因为origin在安全领域是一个比较核心的概念。Origin在这里只是表示一组隔离特性,它并不能解决所有的问题,接下来讨论same-origin的几个弱点。
对DNS的依赖(Reliance on DNS)
实际场景中,same-origin机制依赖于DNS域名解析服务,因为现在流行的URI scheme都使用DNS,比如HTTP。如果DNS服务被攻击了,那么same-origin机制不能为应用提供安全保障。
其他的URI scheme,比如https,在DNS受攻击时,可以保证应用需要的安全性,因为https可以为浏览器提供其他安全机制,比如可以验证从URI下载的证书来确保内容的安全性。其他的URI scheme,比如chrome-extension使用基于公钥的命名授权可以提供更好的安全机制。
Origin机制可以隔离来自不同URI的内容,这样可以消除DNS攻击的部分影响。
隔离粒度(Divergent Units of Isolation)
随着时间地推移,很多网络技术认为Origin是比较合理的隔离粒度。然而,现在比较流行的网络技术,比Origin的概念出现地还要早,比如cookies,这些技术有其他的隔离粒度,所以会导致一些网络漏洞。
可以选择使用注册机构管理(registry-controlled)的域名作为一个域(比如使用example.com而不是www.example.com)。这个方案有一些问题,所以不推荐使用。
- 注册机构(registry-controlled)域名只是方便我们使用的一种简便方式。比如,在日本,很多地级市的运行的DNS服务器,在DNS层级结构中往往比较深。有一些常用的"public suffix lists",但是这些列表的值很难保持最新。
- 不能与不使用基于DNS命名授权的URI scheme保持兼容。比如某个URI scheme使用公钥作为命名授权机制。再或者某些URI scheme,比如nntp,解析点号的顺序与DNS解析点号的方向刚好相反(比如alt.usenet.kook)。再或者,某些URI scheme使用DNS但是其中的字符是反方向排列(比如com.example.www)。
环境权限(Ambient Authority)
IDNA依赖和迁移(IDNA Dependency and Migration)
Same-origin机制的安全性严重依赖浏览器使用的IDNA算法。某些浏览器可能根据使用IDNA2003或者IDNA2008把某些国际域名映射成不同的ASCII值。
从一个IDNA算法迁移到另一个IDNA算法会重新界定某些安全范围,有可能会重新建立安全边界或者把两个互不信任的两个实体的安全边界拆除。把两个互不信任的实体放入同一个origin会非常的危险,因为这样可能导致其中一个攻击另一个。
IANA相关
Header field name: OriginApplicable protocol: httpStatus: standardAuthor/Change controller: IETFSpecification document: this specification (Section 7)
本文翻译自:https://datatracker.ietf.org/doc/html/rfc6454
深入理解Same-Origin安全机制相关推荐
- 甘利俊一 | 信息几何法:理解深度神经网络学习机制的重要工具
智源导读:深度学习的统计神经动力学主要涉及用信息几何的方法对深度随机权值网络进行研究.深度学习技术近年来在计算机视觉.语音识别等任务取得了巨大成功,但是其背后的数学理论发展却很滞后.日本理化所的Shu ...
- 深入理解js的执行机制
写在前面 javascript在浏览器中被浏览器的js引擎执行解释,从执行上下文的角度分析一下js的执行机制 执行上下文 执行上下文被定义成javascript引擎在处理理解js代码时,所创建的一个动 ...
- (转载)彻底理解浏览器的缓存机制
彻底理解浏览器的缓存机制 2018/04/16 概述 浏览器的缓存机制也就是我们说的HTTP缓存机制,其机制是根据HTTP报文的缓存标识进行的,所以在分析浏览器缓存机制之前,我们先使用图文简单介绍一下 ...
- mysql 锁机制 mvcc_轻松理解MYSQL MVCC 实现机制
轻松理解MYSQL MVCC 实现机制 轻松理解MYSQL MVCC 实现机制 #### 1. MVCC简介 ##### 1.1 什么是MVCC MVCC是一种多版本并发控制机制. ##### 1.2 ...
- 深入BCB理解VCL的消息机制
深入BCB理解VCL的消息机制 引子:本文所谈及的技术内容都来自于Internet的公开信息.由笔者在闲暇之际整理 后,贴出来以飴网友,姑且妄称原创.每次在国外网站上找到精彩文章的时候,心中都 会暗自 ...
- 我理解的Hanlder--android消息传递机制
每一个学习Android的同学都会觉得Handler是一个神奇的东西,我也一样,开始我以为我懂了Handler的机制,后来发现自己是一知半解,昨天想想,我能否自己实现一个Handler,让子线程与Ac ...
- 深入理解 Java 垃圾回收机制
转载自 http://www.cnblogs.com/andy-zcx/p/5522836.html 深入理解 Java 垃圾回收机制 一:垃圾回收机制的意义 java 语言中一个显著的特点就是引入 ...
- 轻松理解—继承成员访问控制机制
在我们学习面向对象程序设计的时候,那么这个继承成员访问控制机制您必须对其有深入的了解,达到熟练掌握的目的:要不也许这点知识你不过关,你对这点知识还抱着半信半疑的感觉,那么你一旦碰到这个问题,你的第一个 ...
- serversocket 返回浏览器图片_深入理解浏览器的缓存机制
戳蓝字「前端技术优选」关注我们哦! 一.前言 缓存可以说是性能优化中简单高效的一种优化方式了.一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽 ...
- 你有真正理解 Java 的类加载机制吗?| 原力计划
作者 | 宜春 责编 | Elle 出品 | CSDN 博客 你是否真的理解Java的类加载机制?点进文章的盆友不如先来做一道非常常见的面试题,如果你能做出来,可能你早已掌握并理解了Java的类加载机 ...
最新文章
- 关于CSS 3 及浏览器兼容性问题
- rsync同步操作 、 发布rsync共享 、 inotify实时同步 、 Split分离解析
- 微软雅黑的应用[补充中]
- 相机+激光雷达重绘3D场景
- .net core入门之web应用
- jsonpickle数据序列化
- protected访问权限_复习封装与访问控制
- MDOP套装之app-v安装使用及功能说明
- android studio maven gradle,Maven Dependencies with Android Studio / Gradle
- php js获取session,原创:PHP与纯JS交互在当前页面读取SESSION不用AJAX等
- ubuntu16.04卸载火狐,Amazon
- 变分模态分解(VMD)运算步骤及源码解读
- 固高控制卡学习(vs2010,c++)(之一)
- vbm 分析_VBM
- pdf虚拟打印机下载win7_如何将不同形式的PDF文档进行压缩?
- Django 之 Views
- 2020-09-07(基于控制台的DVD管理系统)
- php如何实现性格测试,一个很准的性格测试
- is not eligible for getting processed by all BeanPostProcessors 导致找不到路径报404
- ant-design中Input输入框在获取焦点时由于保留了上次输入内容而莫名出现了一个黑色背景的选择提示框,且选择提示框中的值后还会出现蓝色背景
热门文章
- linux服务被植入挖矿(2t3ik与ddgs)解决方式
- IDL文件详解[转]
- TopCoder简介
- 利用匿名管道实现远程CMD---我的解读
- supervisor的使用与管理
- 【学习记录】状语和状语从句
- 怎么建一个新的微信群?微信小技巧
- 20 虚幻4【UE4】场景中模型高亮轮廓
- MySQL中的char和varcharmysql中varchar能存多少汉字、数字,以及varchar(100)和varchar(10)的区别
- Springboot 整合Websocket+Stomp协议+RabbitMQ做消息代理 实例教程