打破 iframe 安全限制的 3 种方法
关注「前端向后」微信公众号,你将收获一系列「用心原创」的高质量技术文章,主题包括但不限于前端、Node.js以及服务端技术
一.从 iframe 说起
利用iframe
能够嵌入第三方页面,例如:
<iframe style="width: 800px; height: 600px;" src="https://www.baidu.com"/>
然而,并非所有第三方页面都能够通过iframe
嵌入:
<iframe style="width: 800px; height: 600px;" src="https://github.com/join"/>
Github 登录页并没有像百度首页一样乖乖显示到iframe
里,并且在 Console 面板输出了一行错误:
Refused to display ‘https://github.com/join’ in a frame because an ancestor violates the following Content Security Policy directive: “frame-ancestors ‘none'”.
这是为什么呢?
二.点击劫持与安全策略
没错,禁止页面被放在iframe
里加载主要是为了防止点击劫持(Clickjacking):
具体的,对于点击劫持,主要有 3 项应对措施:
- CSP(Content Security Policy,即内容安全策略)
- X-Frame-Options
- framekiller
服务端通过设置 HTTP 响应头来声明 CSP 和X-Frame-Options
,例如:
# 不允许被嵌入,包括<frame>, <iframe>, <object>, <embed> 和 <applet>
Content-Security-Policy: frame-ancestors 'none'
# 只允许被同源的页面嵌入
Content-Security-Policy: frame-ancestors 'self'
# 只允许被白名单内的页面嵌入
Content-Security-Policy: frame-ancestors www.example.com
# 不允许被嵌入,包括<frame>, <iframe>, <embed> 和 <object>
X-Frame-Options: deny
# 只允许被同源的页面嵌入
X-Frame-Options: sameorigin
# (已废弃)只允许被白名单内的页面嵌入
X-Frame-Options: allow-from www.example.com
P.S.同源是指协议、域名、端口号都完全相同,见Same-origin policy
P.S.另外,还有个与frame-ancestors
长得很像的frame-src
,但二者作用相反,后者用来限制当前页面中的<iframe>
与<frame>
所能加载的内容来源
至于 framekiller,则是在客户端执行一段 JavaScript,从而反客为主:
// 原版
<script>
if(top != self) top.location.replace(location);
</script>
// 增强版
<style> html{display:none;} </style>
<script>
if(self == top) {
document.documentElement.style.display = 'block';
} else {
top.location = self.location;
}
</script>
而 Github 登录页,同时设置了 CSP 和X-Frame-Options
响应头:
Content-Security-Policy: frame-ancestors 'none';
X-Frame-Options: deny
因此无法通过iframe
嵌入,那么,有办法打破这些限制吗?
三.思路
既然主要限制来自 HTTP 响应头,那么至少有两种思路:
- 篡改响应头,使之满足
iframe
安全限制 - 不直接加载源内容,绕过
iframe
安全限制
在资源响应到达终点之前的任意环节,拦截下来并改掉 CSP 与X-Frame-Options
,比如在客户端收到响应时拦截篡改,或由代理服务转发篡改
而另一种思路很有意思,借助Chrome Headless加载源内容,转换为截图展示到iframe
中。例如Browser Preview for VS Code:
Browser Preview is powered by Chrome Headless, and works by starting a headless Chrome instance in a new process. This enables a secure way to render web content inside VS Code, and enables interesting features such as in-editor debugging and more!
也就是说,通过 Chrome 正常加载页面,再将内容截图放到iframe
里,因而不受上述(包括 framekiller 在内的)安全策略的限制。但这种方案也并非完美,存在另一些问题:
- 全套交互事件都需要适配支持,例如双击、拖拽
- 部分功能受限,例如无法拷贝文本,不支持播放音频等
四.解决方案
客户端拦截
Service Worker
要拦截篡改 HTTP 响应,最先想到的,自然是 Service Worker(一种Web Worker):
A service worker is an event-driven worker registered against an origin and a path. It takes the form of a JavaScript file that can control the web-page/site that it is associated with, intercepting and modifying navigation and resource requests.
(摘自Service Worker API)
注册 Service Worker 后能够拦截并修改资源请求,例如:
// 1.注册Service Worker
navigator.serviceWorker.register('./sw-proxy.js');
// 2.拦截请求(sw-proxy.js)
self.addEventListener('fetch', async (event) => {
const {request} = event;
const response = await fetch(request);
// 3.拷贝克隆请求
// 4.篡改响应头
response.headers.delete('Content-Security-Policy');
response.headers.delete('X-Frame-Options');
event.respondWith(Promise.resolve(originalResponse));
});
注意,Fetch Response 无法直接修改请求头,需要手动拷贝克隆,见How to alter the headers of a Response?
P.S.完整实现案例,可参考DannyMoerkerke/sw-proxy
WebRequest
如果是在 Electron 环境,还可以借助WebRequest API来拦截并篡改响应:
const { session } = require('electron')
session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
callback({
responseHeaders: {
...details.responseHeaders,
'Content-Security-Policy': ['default-src 'none'']
}
})
})
(摘自CSP HTTP Header)
但与 Service Worker 类似,WebRequest 同样依赖客户端环境,而出于安全性考虑,这些能力在一些环境下会被禁掉,此时就需要从服务端寻找出路,比如通过代理服务转发
代理服务转发
基本思路是通过代理服务转发源请求和响应,在转发过程中修改响应头甚至响应体
具体实现上,分为 2 步:
- 创建代理服务,篡改响应头字段
- 客户端请求代理服务
以为 HTTPS 为例,代理服务简单实现如下:
const https = require("https");
const querystring = require("querystring");
const url = require("url");
const port = 10101;
// 1.创建代理服务
https.createServer(onRequest).listen(port);
function onRequest(req, res) {
const originUrl = url.parse(req.url);
const qs = querystring.parse(originUrl.query);
const targetUrl = qs["target"];
const target = url.parse(targetUrl);
const options = {
hostname: target.hostname,
port: 80,
path: url.format(target),
method: "GET"
};
// 2.代发请求
const proxy = https.request(options, _res => {
// 3.修改响应头
const fieldsToRemove = ["x-frame-options", "content-security-policy"];
Object.keys(_res.headers).forEach(field => {
if (!fieldsToRemove.includes(field.toLocaleLowerCase())) {
res.setHeader(field, _res.headers[field]);
}
});
_res.pipe(res, {
end: true
});
});
req.pipe(proxy, {
end: true
});
}
客户端iframe
不再直接请求源资源,而是通过代理服务去取:
<iframe style="width: 400px; height: 300px;" src="http://localhost:10101/?target=https%3A%2F%2Fgithub.com%2Fjoin"/>
如此这般,Github 登录页就能在iframe
里乖乖显示出来了:
iframe github login
参考资料
- Clickjacking Defense Cheat Sheet
- 6.3.2. frame-ancestors
- CSP Cheat Sheet
联系我
如果心中仍有疑问,请查看原文并留下评论噢。(特别要紧的问题,可以直接微信联系 ayqywx )
上一篇: 服务器端和客户端的区别是什么?
推荐阅读
-
打破 QuestionStar 输入框粘贴限制的两种方法
-
限制 Pod 磁盘容量的 3 种方法。
-
限制 K8S Pod 磁盘容量使用的 3 种方法
-
打破 iframe 安全限制的 3 种方法
-
在 Windows 11 上下载和安装 Windows 安全软件的 3 种方法 - 如何在 Windows 11 上获取 Windows 安全软件?
-
在 Redis 中限制流量的 3 种方法
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)
-
三种突破iframe安全限制的方法