iframe如何嵌套页面以及规避劫持风险

记得要微笑

1、iframe如何嵌套页面

我们先来说一个场景,比如后台管理中心外围架构在一个项目中维护,而内容部分采用iframe形式嵌入,有同学可能会问为什么不放在同一个项目中维护呢?这是因为放在同一个项目中维护会导致项目过于臃肿,其次是因为内容部分可能由不同项目组来负责,因此可能会采用上述方式。

举个例子说明一下iframe是如何使用的:

假如,现在本地有一个页面A应用,页面A嵌套已经部署到linux服务器上的页面B

在本地写了一个index.html,使用http-server启动服务:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  // 嵌套页面B
  <iframe src="http://47.111.228.207:8080/#/pageA" frameborder="0" width="100%" height="1000" scrolling="no"></iframe>
</body>
</html>

页面B(http://47.111.228.207:8080/#/pageA)是我之前部署在linux服务器上的一个react页面,我们来看看效果:
在index.html中我们嵌套了一个iframe,指向我之前部署在服务器上的

现在浏览器打开http://localhost:8080/
image.png

可以看到已经成功将页面B嵌套进去了。

2、如何规避iframe使用的风险

上面我们已经将页面B成功嵌入到页面A中,但是别人有个页面C将页面B嵌入到他们的页面中,发现也会嵌入成功,那么这就会有问题。如果很多个网站将我们的页面拿过去用,我们的产品就被别人白嫖了,严重点会导致流量流失,甚至他们还可能在前面中嵌入一些恶心小广告,谋取私利(用户并不能区分正在使用的页面是我们的还是别人嵌套过去的)。

那么,如何去规避这些风险呢?

常见方式是在apache 或者 tomcat服务器上配置X-Frame-Options响应头

X-Frame-Options
是为了减少点击劫持(Clickjacking)而引入的一个响应头,这个响应头支持三种配置:

  • DENY:不允许被任何页面嵌入;
  • SAMEORIGIN:不允许被本域以外的页面嵌入,一般设置成该字段即可;
  • ALLOW-FROM uri:不允许被指定的域名以外的页面嵌入(Chrome现阶段不支持);

我们来试试如何在tomcat配置响应头:

进入到usr/local/tomcat/conf/,使用vi web.xml编辑web.xml文件,找到如下配置:
image.png
可以看到初始这部分被注释掉了,现在将这部分改成:

<filter>
    <filter-name>httpHeaderSecurity</filter-name>
    <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
    <init-param>
        <param-name>antiClickJackingOption</param-name>
        <param-value>SAMEORIGIN</param-value>
    </init-param>
    <async-supported>true</async-supported>
</filter>
<filter-mapping>
    <filter-name>httpHeaderSecurity</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

注意:一定要记得去掉<!-- -->注释,不然不会生效!!!

最后,重启tomcat,再次请求,发现服务器拒绝了我们的请求

image.png

并且,响应头中多出了以下几个字段
image.png

X-XSS-Protection

        这个响应头是用来防范XSS的,现在主流浏览器都支持,并且默认都开启了XSS保护,用这个header可以关闭它。它有几种配置:

  • 0:禁用XSS保护;
  • 1:启用XSS保护;
  • 1; mode=block:启用XSS保护,并在检查到XSS攻击时,停止渲染页面(例如IE8中,检查到攻击时,整个页面会被一个#替换);

        浏览器提供的XSS保护机制并不完美,但是开启后仍然可以提升攻击难度,总之没有特别的理由,不要关闭它。

X-Content-Type-Options

        互联网上的资源有各种类型,通常浏览器会根据响应头的Content-Type字段来分辨它们的类型。例如:"text/html"代表html文档,"image/png"是PNG图片,"text/css"是CSS样式文档。然而,有些资源的Content-Type是错的或者未定义。这时,某些浏览器会启用MIME-sniffing来猜测该资源的类型,解析内容并执行。

例如,我们即使给一个html文档指定Content-Type为"text/plain",在IE8-中这个文档依然会被当做html来解析。利用浏览器的这个特性,攻击者甚至可以让原本应该解析为图片的请求被解析为JavaScript。通过下面这个响应头可以禁用浏览器的类型猜测行为:

这个响应头的值只能是nosniff,可用于IE8+和Chrome。

X-Content-Type-Options: nosniff 

X-Content-Security-Policy

        这个响应头主要是用来定义页面可以加载哪些资源,减少XSS的发生。请参考:https://imququ.com/post/content-security-policy-reference.html

参考:
https://www.pianshen.com/arti...
https://www.cnblogs.com/wdnnc...
https://developer.mozilla.org...

阅读 2.1k
avatar
记得要微笑
前端工程师

求上而得中,求中而得下,求下而不得

1.2k 声望
3k 粉丝
0 条评论
avatar
记得要微笑
前端工程师

求上而得中,求中而得下,求下而不得

1.2k 声望
3k 粉丝
文章目录
宣传栏