阅读 184

前端中那些常见的安全知识

面试中会被问到一些安全知识,所以深入一点整理一下,如果理解有错也望纠正。觉得有用的话点个赞呗~

HTTPS的安全性

http

HTTP:超文本传输协议,是一个基于请求与响应无状态无连接的应用层协议,常基于TCP/IP协议传输数据。

HTTP在传输数据的过程中,所有数据都是明文传输,相对来说比较简单快速,灵活。

针对HTTP无状态的一些解决策略:

  • 通过Cookie/Session技术
  • HTTP/1.1持久连接(HTTP keep-alive)方法,只要任意一端没有明确提出断开连接,则保持TCP连接状态,在请求首部字段中的Connection: keep-alive即为表明使用了持久连接。

https

HTTPS基于HTTP协议,通过SSL或TLS提供加密处理数据验证对方身份以及数据完整性保护

http和https的区别

HTTPS = HTTP + SSL / TLS image.png

  • 安全性

    HTTP明文传输,不对数据进行加密,安全性较差。HTTPS传输过程对数据进行加密,安全性较强。

  • 响应速度

    由于加了一层安全层,建立连接的过程更加复杂,也要交换更多的数据,HTTPS的响应速度比HTTP慢。

  • 成本

    HTTPS协议需要申请CA证书,功能越强大的证书费用越高。

  • 服务器资源

    由于 HTTPS 是建构在 SSL / TLS 之上的 HTTP 协议,所以,要比 HTTP 更耗费服务器资源,访客量大的网站需要投入更大的成本。

  • 端口号

    HTTP端口号为80,HTTPS则为443。

https如何保证通信安全

HTTPS 的整个通信过程可以分为两大阶段:证书验证数据传输阶段,数据传输阶段又可以分为非对称加密对称加密两个阶段。

HTTPS通信整个流程:

1.客户端请求 HTTPS 网址,然后连接到 server 的 443 端口

2.采用 HTTPS 协议的服务器必须要有一套数字 CA 证书。

(证书是需要申请的,并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被篡改。)

3.服务器响应客户端请求,将证书传递给客户端

(证书包含公钥和大量其他信息,比如证书颁发机构信息,公司信息和证书有效期等。)

4.客户端解析证书并对其进行验证

(如果证书不是可信机构颁布,或者证书中的域名与实际域名不一致,或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。)

如果证书没有问题,客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY,并使用公钥A将其加密。

5.客户端把加密后的随机码 KEY 发送给服务器,作为后面对称加密的密钥。

6.服务器在收到随机码 KEY 之后会使用私钥B将其解密

经过以上这些步骤,客户端和服务器终于建立了安全连接。

7.服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端,客户端使用相同的密钥 (随机码 KEY)解密数据。双方使用对称加密传输所有数据

数据传输阶段

HTTPS使用加密算法解决数据传输安全问题,具体来说是对称加密和非对称加密的混合使用

对称加密——数据

加密和解密都是使用同一个密钥,常见的对称加密算法有DES、3DES和AES等。

优点:算法公开、计算量小、加密速度快、加密效率高,适合加密比较大的数据

缺点:

  • 由于交易双方需要使用相同的密钥,所以要进行密钥的传输,而密钥在传输过程中无法保证不被截获,因此对称加密的安全性得不到保证。
  • 每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一密钥,这会使得发收信双方所拥有的钥匙数量急剧增长,密钥管理成为双方的负担。

在数据传输过程中,被加密的数据变成无规则的乱码,即便被第三方截获,在没有密钥的情况下也无法解密数据,这就保证了数据的安全。

但是有一个致命的问题,那就是既然双方要使用相同的密钥,那就必然要在传输数据之前先由一方把密钥传给另一方,那么在此过程中密钥就很有可能被截获,这样一来加密的数据也会被轻松解密。

那如何确保密钥在传输过程中的安全呢?这就要用到非对称加密了。

非对称加密——密钥

加密和解密需要使用两个不同的密钥:公钥(public key)和私钥(private key)。常用的非对称加密算法是 RSA 算法。

公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密;如果用私钥对数据进行加密,那么只有用对应的公钥才能解密。

非对称加密算法实现机密信息交换的基本过程是:

甲方生成一对密钥并将其中的一把作为公钥对外公开;得到该公钥后乙方使用公钥对机密信息进行加密后再发送给甲方;甲方再用自己保存的私钥对加密后的信息进行解密。

优点:算法公开,加密和解密使用不同的钥匙,私钥不需要通过网络进行传输,安全性很高。

缺点:计算量比较大,所以加密和解密速度相比对称加密慢很多。

在密钥传输的过程中,客户端在拿到服务器的公钥后,会生成一个随机码 (用 KEY 表示,这个 KEY 就是后续双方用于对称加密的密钥),然后客户端使用公钥把 KEY 加密后再发送给服务器,服务器使用私钥将其解密,这样双方就有了同一个密钥 KEY,然后双方再使用 KEY 进行对称加密交互数据。

在非对称加密传输 KEY 的过程中,即便第三方获取了公钥和加密后的 KEY,在没有私钥的情况下也无法破解 KEY (私钥存在服务器,泄露风险极小),也就保证了接下来对称加密的数据安全。

SSL / TLS 以及 SSL / TLS 握手

SSL 和 TLS 协议可以为通信双方提供识别和认证通道,从而保证通信的机密性和数据完整性。

SSL:(Secure Socket Layer,安全套接字层),位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。

TLS:(Transport Layer Security,传输层安全协议)。

两者的关系: 最新版本的TLS是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别,主要是它们所支持的加密算法不同,所以TLS与SSL3.0不能互操作。

TLS三次握手的具体过程

在 TLS 握手的过程中,通信双方交换消息以相互验证,相互确认,并确立它们所要使用的加密算法以及会话密钥。

  • "client hello"消息:客户端通过发送"client hello"消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择,还有一个"client random"随机字符串

  • "server hello"消息:服务器发送"server hello"消息对客户端进行回应,该消息包含了数字证书,服务器选择的密码组合和"server random"随机字符串

  • 验证:客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:

    • 检查数字签名
    • 验证证书链
    • 检查证书的有效期
    • 检查证书的撤回状态 (撤回代表证书已失效)
  • "premaster secret"字符串:客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)",这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密。

  • 私钥解密预主密钥:服务器使用私钥解密"premaster secret"。

  • 生成共享密钥:客户端和服务器均使用 client random,server random 和 premaster secret,并通过相同的算法生成相同的共享密钥 KEY

  • 客户端就绪:客户端发送经过共享密钥 KEY加密过的"finished"信号

  • 服务器就绪:服务器发送经过共享密钥 KEY加密过的"finished"信号

  • 达成安全通信:握手完成,双方使用对称加密进行安全通信

https一定是安全的吗?

image.png

  • HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用

  • SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行

中间人攻击(MITM攻击)是指,黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM,被动MITM只窃取通信数据而不修改,而主动MITM不但能窃取数据,还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。

怎么保证保证服务器给客户端下发的公钥是真正的公钥,而不是中间人伪造的公钥呢?

https握手过程的证书校验环节就是为了识别证书的有效性唯一性等,所以严格意义上来说https下不存在中间人攻击,存在中间人攻击的前提条件是没有严格的对证书进行校验,或者人为的信任伪造证书。 image.png

验证证书安全性过程:

当客户端收到这个证书之后,使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名,数字签名经过CA公钥解密得到证书信息摘要

然后用证书签名的方法计算一下当前证书的信息摘要,与收到的信息摘要作对比,如果一样,表示证书一定是服务器下发的,没有被中间人篡改过。因为中间人虽然有权威机构的公钥,能够解析证书内容并篡改,但是篡改完成之后中间人需要将证书重新加密,但是中间人没有权威机构的私钥,无法加密,强行加密只会导致客户端无法解密,如果中间人强行乱修改证书,就会导致证书内容和证书签名不匹配。

那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢?

(伪装服务端一样的配置)显然这个是不行的,因为当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证明你是服务端域名的拥有者,而第三方攻击者是无法提供这些信息所以他就是无法骗CA他拥有属于服务端的域名。

参考

segmentfault.com/a/119000002…

blog.csdn.net/xiaoming100…

OAuth2.0

占个坑

浏览器同源策略

如果两个URL的协议域名端口号都相同,则它们是同源的。浏览器存在同源限制,它是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源。同源策略的目的,是为了保证用户信息的安全,防止恶意的网站窃取数据。

浏览器同时规定,提交表单不受同源政策的限制。

如果非同源,一共有三种行为受到限制。

  • cookie、localstorage和indexDB无法读取
    • 一级域名相同,二级域名不同,设置document.domain共享cookie(LocalStorage 和 IndexDB 无法通过这种方法,规避同源政策)
  • DOM无法获得
    • 一级域名相同,二级域名不同,设置document.domain拿到DOM
  • Ajax请求不能发送
    • jsonp
    • websocket协议不实行同源政策
    • CORS跨域资源共享
    • 架设服务器代理

参考:

www.ruanyifeng.com/blog/2016/0… 浏览器同源政策及其规避方法

cookie和session、token

HTTP是无状态的,不会记住用户,即使你刚刚才使用账号密码登录过系统,当你下一次发起请求,还是会再次校验你的身份。常用做身份校验的方式有session和token,而cookie只是作为一个数据存储的载体。

session

Session是对于服务端来说的,客户端是没有Session一说的。Session是服务器在和客户端建立连接时添加客户端连接标志,最终会在服务器软件(Apache、Tomcat、JBoss)转化为一个临时Cookie发送给给客户端,当客户端第一请求时服务器会检查是否携带了这个Session(临时Cookie),如果没有则会添加Session,如果有就拿出这个Session来做相关操作。

认证流程

  • 用户使用账号密码登录服务器
  • 服务器生成一个session对象和与之对应的sessionid,用来记录用户的会话信息,并将sessionid返回给浏览器,浏览器可以使用cookie、localStorage或sessionStorage进行存储
  • 浏览器下次向服务器发起请求,会带上sessionid
  • 服务器收到sessionid,先查看是否存在与之对应的session对象,如果有,认证成功并返回数据,如果没有则要求重新登录

session对象存储在服务器端,客户端登录以后,每次请求只需带上sessionid即可完成身份认证。但是,当服务器采用分布式或集群时,用户在服务器A登录,下次请求到了另一台服务器B,就得重新登录,这是无法接受的,解决方式有以下几种:

session保持:保证每个客户固定地访问同一台服务器 session复制:将所有session对象复制到所有服务器 session共享:把所有session放到同一台服务器

不管哪一种,都得付出额外的成本,并且,随着用户量增大,服务器将创建大量的session对象,对服务器来说是个负担。

token

token是用户身份的验证方式,我们通常叫它:令牌。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token,避免多次查库。

认证流程

  • 用户使用账号密码登录服务器
  • 服务器用特定的算法生成一个签名的token保存在数据库中,并返回给客户端
  • 客户端拿到token后进行本地存储,后续每次请求都带上token
  • 服务器收到请求后,取出token与数据库中的token做对比
    • 如果两个token值相同,则说明用户当前处于登录状态
    • 如果没有这个token值,则说明还没有登陆或登陆未成功
    • 如果两个token值不同,说明原来登录状态已经失效,让用户重新登陆

Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端。对于这一点来说,使用token服务器压力不会随着用户量增加而急剧增大。

cookie

Cookie 在计算机中是个存储在浏览器目录中的文本文件,当浏览器运行时,存储在 RAM 中发挥作用 (此种 Cookies 称作 Session Cookies),一旦用户从该网站或服务器退出,Cookie 可存储在用户本地的硬盘上 (此种 Cookies 称作 Persistent Cookies)。

cookie不是一种认证机制,它和localStorage以及sessionStorage才是同类,由于每次HTTP请求都会自动带上cookie,它常常被用来存储用户认证相关数据。也正是因为每次HTTP请求都会自动带上cookie,才有了CSRF问题,CSRF问题可以通过不把用户认证信息存在cookie里进行解决。

参考链接

juejin.cn/post/694488…

XSS

跨站脚本攻击(Cross Site Scripting),是指利用网页开发时留下的漏洞,通过注入不安全脚本到网页,使用户加载并执行攻击者恶意制造的脚本程序。

常见场景

  • 利用脚本窃取用户的 Cookie 值,被害者在不知情的情况下,帮助攻击者发送恶意请求。

  • 一些带有用户留言功能的网站。比如攻击者A在留言中写入了一段攻击代码,这段代被发送到服务器,并且没有经过转义过滤,当用户B访问网页的时候,获取了这段代码并直接执行了,这就产生了XSS攻击。

类型

  • DOM xss

    不需要服务器解析相应的直接参与,触发XSS靠的是浏览器端的DOM解析

  • 反射型 xss (非持久性XSS)

    特点在于即时性,它可以不需要存储在服务器中,通过巧妙地构造一个带恶意代码的URL,然后引导用户点击访问,即可实现攻击。

    比如一个页面把url上面的参数内容放到网页中,而且没有对query进行过滤,直接将query参数内容插入到DOM中。如果这个query参数内容是一段恶意脚本,或者说是类似这样委婉的写法q=<img src="" onerror="alert(document.cookie)",因为是插入一张图片,浏览器一般不会做过滤拦截,然后我们把src置空使其触发onerror事件,间接地执行我们的恶意脚本,这就触发XSS攻击了。

  • 存储型 xss (持久性XSS)

    假如某个网站的评论区也未作过滤的安全处理,那么我们就可以通过评论的方式将恶意脚本提交至后台服务器接收并存储,之后任何访问了此评论页面的用户,都会执行到这个代码,从而达到攻击目的。

    因为保存在了数据库,所以具有持久性。而且也不需要诱导用户点击恶意链接,更容易达到攻击的目的,因此危害性更强。

如何防范

  • 设置HttpOnly

    在 cookie 中设置 HttpOnly 属性,禁止Javascript通过document.cookie获得。

  • 过滤

    • 输入检查

      一般是用于对于输入格式的检查,例如:邮箱,电话号码,用户名,密码等,按照规定的格式输入。

      前端后端都需要做过滤检查,因为攻击者可能会绕过正常的输入流程,直接利用相关接口向服务器发送设置。

    • HtmlEncode

      净化和过滤掉不必要的 html 标签。当用户输入<script>window.location.href=”http://www.baidu.com”;</script>, 最终保存结果为 &lt;script&gt;window.location.href=&quot;http://www.baidu.com&quot;&lt;/script&gt;, 在展现时,浏览器会对这些字符转换成文本内容,而不是一段可以执行的代码。

    • JavaScriptEncode

      对下列字符加上反斜杠。

      image.png

  • csp 内容安全策略

    网站在HTTP头部中设置Content-Security-Policy,来告诉浏览器什么是被授权执行的与什么是需要被禁止的。CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供配置。更多内容可以看下面这篇博客 blog.csdn.net/qq_37943295…

参考链接

juejin.cn/post/684490…

CSRF

跨站请求伪造(CRSF Cross Site Request Forgery), 冒充用户发起请求(在用户不知情的情况下), 完成一些违背用户意愿的事情(如修改用户信息,删初评论等)。

CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。也就是说,简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。

攻击流程

1、受害者登录目标网站A;

2、受害者以某种方式接触到恶意网站B的链接;

3、受害者点击链接访问网站B, 网站B中的js代码执行, 偷偷向目标网站A发送某个请求;

4、由于受害者登录过网站A, 因此请求携带了网站A的相关cookie凭证,最后请求成功执行;

在这个过程中,由于浏览器存在跨域限制,恶意网站可以通过以下两种方法对目标网站发起请求:

  • 对于GET请求,img标签链接不受浏览器的跨域限制,因此可以直接以img的形式发起请求;

  • 对于POST请求,可以通过CORS方法。

如何防范

CSRF的攻击虽然能够伪造用户的信息,但是这样的请求毕竟是从第三方网站发起的,并不会经过正规网站本身。因此客户端也无法通过代码来阻止请求的发起,不过关键一步在于恶意请求发起需要带上身份凭据,请求才能被通过和执行。

  • sameSite-Strict属性

    通过设置sameSite-Strict属性,禁止第三方网站携带cookie。

  • Referer字段

    由于CSRF都是通过三方网站发起,因此我们如果能判断服务器每次收到的请求来自哪些网站,就可以过滤那些存在安全风险的网站发起的请求,降低被攻击的风险。

    RefererOrigin是http请求的头部字段之一,用来标志该请求是从哪个页面链接过来的。Origin 属性只包含了域名信息,并没有包含具体的 URL 路径,这是 Origin 和 Referer 的一个主要区别。

    后台服务器可以通过检查该字段是否是来自自己的网站链接,来避免第三方网站发起CSRF攻击。服务器的策略是优先判断 Origin,如果请求头中没有包含 Origin 属性,再根据实际情况判断是否使用 Referer 值。

  • 验证码

    CSRF的一个特点是伪造请求不会经过网站A,那么我们可以通过增加网站A的验证手段,例如增加图形验证码或短信验证码等,只有通过验证的请求才算合法。

    但是这种方案拥有两个局限性,一个是增加开发成本,另外一个是降低用户体验。

  • token

    CSRF只能通过浏览器发起请求的时候自己带上Cookie,不能操作Cookie来获取到Token并加到http请求的参数或者请求头中,所以token能防止csrf攻击。

    这个方案的具体过程上面讲token的时候谈到了,可以翻上去看看。

Mysql注入

SQL注入是指将Web页面的原URL、表单域或数据包输入的参数,修改拼接成SQL语句,传递给Web服务器,进而传给数据库服务器以执行数据库命令。当Web应用程序的开发人员对用户所输入的数据不进行过滤或验证就直接传输给数据库,就可能导致拼接的SQL被执行,获取数据库的信息以及提权,此时称发生了SQL注入攻击。

如何防范

  • 输入验证

    检查用户输入的合法性,尽量的限制用户输入特殊的符号,确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行。之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。

  • 参数化SQL或存储过程来执行所有的查询

    永远不要使用动态拼装的SQL语句,可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

  • 权限控制

    永远不要使用管理员权限的数据库连接,为每个应用使用单独的权限有限的数据库连接。

  • 错误消息处理

    应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装,把异常信息存放在独立的表中。

界面操作劫持攻击

界面操作劫持攻击是一种基于视觉欺骗的web会话攻击,通过在页面可见控件上覆盖一个不可见的框(iframe),使得用户误以为自己在操作可见框,从而诱使用户在不知情的情况下篡改数据、窃取信息等。

界面劫持攻击大概有三类:

1.点击劫持。 2.拖放劫持。 3.触屏劫持。

常见场景

image.png

  • 黑客创建一个网页利用 iframe 包含目标网站;

  • 隐藏目标网站,使用户无法无法察觉到目标网站存在;

  • 构造网页,诱变用户点击特定按钮;

  • 用户在不知情的情况下点击按钮,触发执行恶意网页的命令。

如何防范

  • X-FRAME-OPTIONS

    X-FRAME-OPTIONS HTTP 响应头是用来给浏览器指示允许一个页面可否在<frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能,来确保自己网站内容没有被嵌到别人的网站中去。

  • JS 判断顶层视口的域名是不是和本页面的域名一致,不一致则不允许操作,但可轻易破解。

function locationTop(){
  if (top.location != self.location) {
     top.location = self.location;
     return false;
  }
  return true; 
 }
locationTop();



// 破解:
// 顶层窗口中放入代码
var location = document.location;
//或者
var location = "";

复制代码

XS-Leaks

跨站泄漏。 XS-Leaks利用了对HTTP缓存进行查询的机制,通过对资源缓存的判断进而推断出当前用户的相关信息

由于浏览器缓存资源没有域名限制,所有网站都共享了缓存资源,因此利用这一点就可以检测用户是否访问过特定的网站:恶意网站通过发起特定的资源请求,通过判断此次资源是否来自缓存就可以推断出用户的浏览历史。比如我在我的网站中请求掘金的LOGO图片,如果我判断出这张图片来自缓存,那我就可以知道该用户访问过掘金网站。

XS-Leaks和上述的原理类似,利用了对HTTP缓存进行查询的机制,通过检测一个查询询问是否有结果来获取一些用户数据。XS-Leaks攻击的主要步骤流程如下:

  • 删除特定网站的缓存资源。

    // 通过发起一个POST请求,就可以清除浏览器对这张图片的缓存。
    FETCH POST http://xxx.com/user/helloWorld.jpg
    复制代码
  • 强制浏览器刷新网站或者重新进入网站。

    通过iframe或者<link ref=rerender href="http://xxx.com/user" />等方式悄悄发起一个请求,访问原本网站,紧接着只需要再请求一次资源,判断其是否来自缓存,如果是,就可以推断出相应的信息。

  • 检查浏览器是否缓存了在(1)中删除的资源。

    如何判断一个请求来自缓存呢?

    一种方法是通过读取img的宽高属性,来判断图片是否来自缓存:

    const img = new Image();
    img.onload = () => {
      // 如果img不是来自缓存,那么只有在图片加载完成触发onload之后,才能拿到实际的witdh值
      console.log(img.width);
    }
    img.src = 'http://xxx.com/user/helloWorld.jpg';
    // 如果存在缓存,在这里可以立即读取到图片的 witdh 值,否则会打印 0
    console.log(img.width);
    复制代码

至此一次XS-Leaks攻击就完成了。我们也可以请求一些带权限的链接来判断用户是否拥有某个网站的特权身份等。

如何防范

XS-Leaks从第三方网站中发起攻击,通过向目标网站发起请求而达到攻击目的,这和csrf很类似。CSRF的防御手段同样可以让XS-Leaks对带鉴权的请求访问无效,从而降低危险。当然有些时候这种攻击其实并不需要鉴权就能达成目的,因此CSRF的防御手段并不能做到完美抵御,所以在浏览器层面增加缓存分区就显得非常有必要了。

  • 设置SameSite
  • Token
  • 浏览器支持缓存分区

window.opener

window.opener 表示打开当前窗体页面的的父窗体的是谁。

例如,在 A 页面中,通过一个带有 target="_blank"a 标签打开了一个新的页面 B,那么在 B 页面里,window.opener 的值为 A 页面的 window 对象。

一般来说,打开同源(域名相同)的页面,不会有什么问题。

但对于跨域的外部链接来说,存在一个被钓鱼的风险。比如你正在浏览购物网站,从当前网页打开了某个外部链接,在打开的外部页面,可以通过 window.opener.location 改写来源站点的地址。利用这一点,将来源站点改写到钓鱼站点页面上,例如跳转到伪造的高仿购物页面,这时候很难发现购物网站的地址已经被修改了的,这个时候你的账号就存在被钓鱼的可能了。

如何防范

  • 设置 rel 属性
<a href="https://xxxx" rel="noopener noreferrer"> 外链 <a>
复制代码

rel="noopener noreferrer" 规定禁止新页面传递源页面的地址,通过设置了此属性的链接打开的页面,其 window.opener 的值为 null。

将外链替换为内部的跳转连接服务,跳转时先跳到内部地址,再由服务器 redirect 到外链。

参考链接

juejin.cn/post/684490…

文章分类
前端
文章标签