Browser Security-同源策略、伪URL的域

同源策略


同源策略的文档模型

同源策略(Same Origin policy,SOP),也称为单源策略(Single Origin policy),它是一种用于Web浏览器编程语言(如JavaScript和Ajax)的安全措施,以保护信息的保密性和完整性。

同源策略能阻止网站脚本访问其他站点使用的脚本,同时也阻止它与其他站点脚本交互。

原始资源 要访问的资源 非IE浏览器 IE浏览器
http://example.com/a/ http://example.com/b/ 可以访问 可以访问
http://example.com/ http://www.example.com/ 主机不匹配 主机不匹配
http://example.com/a/ https://example.com/a/ 协议不匹配 协议不匹配
http://example.com:81/ http://example.com/ 端口不匹配 可以访问

同源策略一开始是为了管理DOM之间的访问,后来逐渐扩展到Javascript对象,但并非是全部。

例如非同源的脚本之间可以调用location.assign()和location.replace()。

同源策略在提高了安全性,但同时也降低了灵活性。

例如很难将login.example.com与payments.example.com两个域之间的数据可以方便的传送。

介绍两种解决方式:document.domain和postMessage()。

javascript允许子域之间使用顶级域名。

例如login.example.com和payments.example.com都可以进行如下设置:

document.domain="example.com"

设置这个属性之后,子域之间可以方便的通信,需注意的是协议和端口号必须相同。

原始资源   访问的资源   结果
URL document.domain URL document.domain  
http://www.example.com/ example.com http://payments.example.com/ example.com 可以访问
http://www.example.com/ example.com https://payments.example.com/ example.com 协议不匹配
http://payments.example.com example.com http://example.com/ (不设置) 拒绝访问
http://www.example.com/ (不设置) http://www.example.com example.com 拒绝访问

postMessage()是HTML5的一个API接口,由于比较新,所以在IE6和IE7中不支持。 1 向另外一个iframe发送消息:

var message = "Hello" + (new Date().getTime());
    window.parent.frames[1].postMessage(message, "*");

iframe1.html需要向iframe2.html发送消息,也就是第二个iframe,所以是window.parent.frames[1]。

如果是向父页面发送消息就是window.parent。

postMessage这个函数接收二个参数,缺一不可,第一个参数即你要发送的数据。

第二个参数是非常重要,主要是出于安全的考虑,一般填写允许通信的域名。

这里为了简化,所以使用’*",即不对访问的域进行判断。

2 另外一个iframe监听消息事件:

iframe2.html中写个监听message事件,当有消息传到iframe2.html时就会触发这个事件。
var onmessage = function(e) {
    var data = e.data,p = document.createElement("p");
    p.innerHTML = data;
    document.getElementById("display").appendChild(p);
};
 //监听postMessage消息事件
if (typeof window.addEventListener != "undefined") {
    window.addEventListener("message", onmessage, false);
 } else if (typeof window.attachEvent != "undefined") {
    window.attachEvent("onmessage", onmessage);
}

如果你有加域名限,比如下面的代码:

window.parent.frames[1].postMessage(message, "http://www.test.com");

就要在onmessage中追加个判断:

if(event.origin !== "http://www.test.com") return;

XMLHttpRequest的同源策略

一个简单的同步XMLHttpRequest请求:

var x = new XMLHttpRequest();
x.open("POST", "/some_script.cgi", false);
x.setRequestHeader("X-Random-Header", "Hi mom!");
x.send("...POST payload here...");
alert(x.responseText);

XMLHttpRequest请求严格遵守同源策略,非同源不可以请求。

这个API也做过很多测试与改进,下面列出之前的测试方法:

var x = new XMLHttpRequest();
x.open("POST", "http://www.example.com/", false);
// 定义发送内容长度为7
x.setRequestHeader("Content-Length", "7");
// 构造的http请求。
x.send(
"Gotcha!\n" +
"GET /evil_response.html HTTP/1.1\n" +
"Host: www.bunnyoutlet.com\n\n"
);

现在的浏览器都不存在上面的隐患,包括基本都禁用了TRACE方法,防止httponly的cookie泄漏问题等。

Web Storage的同源策略

Web Storage是由Mozilla的工程师在Firefox1.5中加入的,并且加入了HTML5中,现在的浏览器都支持,除了IE6与IE7。

JavaScript可以通过localStorage与sessionStorage对Web Storage进行创建,检索和删除:

localStorage.setItem("message", "Hi mom!");
alert(localStorage.getItem("message"));
localstorage.removeItem("message");

localStorage对象可以长时间保存,并且遵守同源策略。

但是在IE8中localStorage会把域名相同但是协议分别为HTTP和HTTPS的内容放在一起,IE9中已修改。

在Firefox中,localStorage没有问题,但是sessionStorage也是会把域名相同的HTTP与HTTPS放在一起。

Cookie的安全策略

设置Cookie总结


在foo.example.com设置cookie,domain设置为:


最终cookie的范围


非IE浏览器


IE浏览器


设置为空


foo.example.com(一个域)


*.foo.example.com


bar.foo.example.com


cookie设置失败,设置的域是当前域的一个子域


foo.example.com


*.foo.example.com


baz.example.com


cookie设置失败,域名不匹配


example.com


*.example.com


ample.com


cookie设置失败,域名不匹配


.com


设置失败,域名太广,存在安全风险。

Cookie中的path参数可以设定指定目录的cookie。

例如设定domain为example.com,path为/some/path/ 在访问下面url的时候会带上设定的cookie:

http://foo.example.com/some/path/subdirectory/hello_world.txt

存在一定的安全风险,因为path的设定没有考虑到同源策略。

httponly属性可以防止通过document.cookie的API访问设定的cookie。

secure属性设定后只有在通过https传输时才会带上设定的cookie,可以防止中间人攻击。

Adobe Flash

AllowScriptAccess参数:用来控制flash通过ExternallInterface.call()函数调用javascript的时的限制。

有三个值:always,never和sameorigin,最后一个值只允许同域的JavaScript操作(08年之前默认为always,现在默认为sameorigin)。

AllowNetworking参数:用来控制flash与外部的网络通讯。

可选的值为:all(允许使用所有的网络通讯,默认值),internal(flash不能与浏览器通讯如navigateToURL,但是可以调用其他的API),none(禁止任何的网络通讯)

本地文件

由于本地文件都是通过file:协议进行访问的,由于不存在host,所以无法遵循同源策略。

所以本地保存的一个HTML文件,在浏览器中通过file:协议访问后,可以通过XMLHttpRequest或DOM对本地其他文件进行操作。

与此同时,也可以对互联网的其他资源做同样的操作。各浏览器厂商意识到这个问题,并努力做了修改:

测试代码:

1.html(1.txt随机写一些字符串即可)

<script>
function createXHR(){
  return window.XMLHttpRequest?
  new XMLHttpRequest():
  new ActiveXObject("Microsoft.XMLHTTP");
}
function getlocal(url){
  xmlHttp = createXHR();
  xmlHttp.open("GET",url,false);
  xmlHttp.send();
  result = xmlHttp.responseText;
  return result;
}
function main(){
  url = "file://路径/1.txt";
  alert(url);
  result = getlocal(url);
  alert(result);
}
main();
</script>

结论:

1 Chrome浏览器(使用WebKit内核的浏览器)
完全禁止跨文档的XMLHttpRequest和DOM操作,并禁止了document.cookie和<meta http-equiv="Set-Cookie" ...>的操作。
2 Firefox
允许访问同目录与子目录里的文件。也可通过document.cookie与<meta http- equiv="Set-Cookie" ...>设定cookie,file:协议下cookie共享,storage也是。
3 IE7及以上
允许本地文件之间的访问,但是在执行JavaScript之前会有一个提示,用户点击通过之后可以执行,cookie域Firefox类似,但是file:协议下不支持storage。
4 IE6
允许本地文件的访问,同时也允许对http协议的访问,cookie也是一样。

伪URL的域



一些web应用用到了伪URL例如about:,javascript:,和data:来创建HTML文档。

这种方法是为了不需要再与服务器通信,可以节约时间更快的响应,但是也带进了很多安全隐患。

about:blank

about协议在现在的浏览器中有很多用途,但是其中大部分不是为了获取正常的页面。

about:blank这个URL可以用来被创建DOM对象,例如:

<iframe src="about:blank" name="test"></iframe>
<script>
frames["test"].document.body.innerHTML = "<h1>Hi!</h1>";
</script>

在浏览器中,创建一个about:blank页面,它继承的域为创建它的页面的域。

例如,点击一个链接,提交一个表单,创建一个新窗口,但是当用户手动输入about:或者书签中打开的话,他的域是一个特殊的域,任何其他的页面都不可以访问。

data:协议

data:协议是设计用来放置小数据的,例如图标之类的,可以减少http请求数量,例如:

<img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEBLAEsAAD...">

用以下代码研究域的问题:

<iframe src="data:text/html;charset=utf-8,<script>alert(document.domain)</script>" >

在Chrome与Safari中,所有的data:都会赋予一个单独的,不可获取的域,而不是从父域中继承的。

Firefox与Opera中,域是继承于当前页面。

IE8之前的版本不支持data:协议。

javascript:和vbscript:

javascript:协议允许后面执行javascript代码,并且继承了调用的当前域。

有些情况会对后面的内容处理两次,如果代码正确的话,会把后面的代码当成html解析,覆盖掉原来的html代码:

<iframe src="javascript:"<b>2 + 2 = " + (2+2) + "</b>"">
</iframe>
时间: 2024-10-13 08:02:59

Browser Security-同源策略、伪URL的域的相关文章

jsonp突破同源策略,实现跨域访问请求

跨域访问问题,相信大家都有遇到过.这是一个很棘手的问题.不过道高一尺,魔高一丈,对于这类问题,总有解决问题的方案.最近我又接触到了这个问题,解决的途径是ajax+jsonp. 说到这个问题,不得不说一下"同源策略(Same-Origin Policy)",它是由Netscape提出的一个著名的安全策略.现在所有支持JavaScript 的浏览器都会使用这个策略.所谓同源,就是必须协议.域名.端口都一致的,才叫做同源.例如:http://www.12306.cn和https://www.

浏览器的同源策略和CORS跨域

浏览器的同源策略和CORS跨域 什么是同源: 域名/ip + 端口 + 协议 http协议默认端口:80 https协议默认端口:443 浏览器对于非同源的请求会拒绝接受响应信息. 前后端分离的项目一般都会涉及到跨域问题 JSONP跨域(之前的解决方案) 不足: 只能GET请求 前端和后端都要支持 原理: 利用的就是浏览器对加载静态资源不做限制,比如 <script src="跨域的地址"></script> jQuery版JSONP $.getJSON(&qu

浏览器同源策略,及跨域解决方案

一.Origin(源) 源由下面三个部分组成: 域名 端口 协议 两个 URL ,只有这三个都相同的情况下,才可以称为同源. 下来就以 "http://www.example.com/page.html" 这个链接来比较说明: 对比URL 结果 原因 http://m.example.com/page.html 不同源 域名不同 https://www.example.com/page.html 不同源 协议不同 http://www.example.com:8080/page.htm

浏览器同源策略与ajax跨域方法汇总

原文 什么是同源策略 如果你进行过前端开发,肯定或多或少会听说过.接触过所谓的同源策略.那么什么是同源策略呢? 要了解同源策略,首先得理解“源”.在这个语境下,源(origin)其实就是指的URL.所以,我们需要先理解URL的组成.看看这个URL: http://www.jianshu.com/p/bc7b8d542dcd 我们可以将它拆解为下面几个部分协议.域名和路径: http :// www.jianshu.com /p/bc7b8d542dcd ${protocol}:// ${host

Jsonp的js实现,跨域请求,同源策略机制

Jsonp的js实现,跨域请求,同源策略机制1.跨域请求:请求URL的协议,域名,端口三者之间任意一个与当前页面地址不同即为跨域 存在跨域的情况: 网络协议不同,端口不通,域名不同,子域名不同,域名和域名对应IP不同2.同源策略机制:(相对情况,保护隐私不被泄露) 同源策略概念(Same-Origin Policy) 同源指:域名,协议,端口相同.不同源的客户端脚本(Javascript,ActionScript)在 没明确授权的情况下,不能读写对方的资源.3.Jsonp的js实现: Jsonp

同源策略——浏览器安全卫士

对于软件开发人员来说,理解同源策略.能够非常好地攻克了一个痛点. 不同域名下的资源读写 ! 古代的楚河汉界明白地规定了两方的活动界限.假设没有这些界限,天下必将大乱.相同,在我们的浏览器,也有着一些界限和策略,才让 Web 世界之所以能如此美好地呈如今我们面前.这些安全策略有效地保障了用户计算机的本地安全与Web安全. 同源策略 浏览器有一个非常重要的概念--同源策略(Same-Origin Policy).所谓同源是指,域名,协议.port同样.不同源的client脚(javascript.A

禁用浏览器同源策略的方法

前后联调的时候总会涉及到跨域,平时我们跨域主要的方法是通过cors进行跨域,但是通过cors进行跨域有的时候会涉及到数据安全的问题,这时候我们可以通过禁用本地浏览器的同源策略来进行跨域的联调 ie的禁用同源策略设置,进入ie的网际网路选项设置,然后选择安全性,再选择自订等级,然后下拉,找到「存取跨网络的资料来源」,选择启用即可. chrome的话可以通过在命令行,输入「chrome --disable-web-security」,它会自己再新开启一个实例,开启chrome的时候显示一系列黄色的文

web安全之同源策略

为什么使用同源策略?一个重要原因就是对cookie的保护,cookie 中存着sessionID .如果已经登录网站,同时又去了任意其他网站,该网站有恶意JS代码.如果没有同源策略,那么这个网站就能通过js 访问document.cookie 得到用户关于的各个网站的sessionID.其中可能有银行网站,通过已经建立好的session连接进行攻击,这里有一个专有名词,CSRF,还有需要注意的是同源策略无法完全防御CSRF,这里需要服务端配合. 什么是同源策略? URL由协议.域名.端口和路径组

同源策略——浏览器的安全卫士

对于软件开发者来说,理解同源策略,可以很好地解决了一个痛点, 不同域名下的资源读写 ! 古代的楚河汉界明确地规定了双方的活动界限,如果没有这些界限,天下必将大乱.同样,在我们的浏览器,也有着一些界限和策略,才让 Web 世界之所以能如此美好地呈现在我们面前,这些安全策略有效地保障了用户计算机的本地安全与Web安全. 同源策略 浏览器有一个很重要的概念--同源策略(Same-Origin Policy).所谓同源是指,域名,协议,端口相同.不同源的客户端脚(javascript.ActionScr