IFrame安全问题解决办法（跨框架脚本(XFS)漏洞）

最近项目要交付了，对方安全测试的时候检测出高危险漏洞，由于刚参加工作不久，经验不足，未涉及过此方面的东西。经过一番查询和探索，最终解决了这个问题，记录一下。 发现的漏洞为缺少跨框架脚本保护。跨框架脚本(XFS)漏洞使攻击者能够在恶意页面的 HTMLiframe 标记内加载易受攻击的应用程序。攻击者可以使用       此漏洞设计点击劫持攻击，以实施钓鱼式攻击、框架探查攻击、社会工程攻击或跨站点请求伪造攻击。个人理解就是其他网站会在他的iframe中调用我的网站内容，来截取他人的点击事件或者窃取他人敏感信息。

在网上查了一下，有这类问题的说明，但是都是告诉要设置什么，却没有说具体在哪里配置。最后只能自己想办法。检测结果中提出了修复的方法：

浏览器供应商已使用 X-Frame-Options标头引入并采用基于策略的缓解技术。如果站点包含在 iframe内，则开发人员可以使用此标头指示浏览器执行相应操作。开发人员必须将X-Frame-Options标头设置为以下允许的值之一:

· DENY拒绝设置页面框架的所有尝试

· SAMEORIGIN仅当另一页面与设置框架的页面属于同一源时，该另一页面才能充当此页面的框架

· ALLOW-FROM源开发人员可以在源属性中指定受信源列表。只有源中的页面才允许在 iframe内部加载此页面

开发人员还必须使用客户端 frame busting JavaScript作为对 XFS的保护。这样也将保护不支持X-Frame-Options标头的旧版本浏览器用户免受点击劫持攻击。

关于X-Frame-Options，具体可以查看一下链接：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/X-Frame-Options

讲解X-Frame-Options的很多，但是具体在哪里设置都不是很明确，看了半天并没有明白，也可能是本人能力有限，最后，个人猜测，我用的tomcat，编写的java web，既然是http响应头，那么不是跟server有关就是跟java web的web.xml有关，经过查看发现在Servers的web.xml中有一个关于X-Frame-Options的注解，在其下方有一个注释掉的filter，如下

1. <!-- ================== Built In Filter Definitions ===================== -->
2. <!-- A filter that sets various security related HTTP Response headers.   -->
3. <!-- This filter supports the following initialization parameters         -->
4. <!-- (default values are in square brackets):                             -->
5. <!--                                                                      -->
6. <!--   hstsEnabled         Should the HTTP Strict Transport Security      -->
7. <!--                       (HSTS) header be added to the response? See    -->
8. <!--                       RFC 6797 for more information on HSTS. [true]  -->
9. <!--                                                                      -->
10. <!--   hstsMaxAgeSeconds   The max age value that should be used in the   -->
11. <!--                       HSTS header. Negative values will be treated   -->
12. <!--                       as zero. [0]                                   -->
13. <!--                                                                      -->
14. <!--   hstsIncludeSubDomains                                              -->
15. <!--                       Should the includeSubDomains parameter be      -->
16. <!--                       included in the HSTS header.                   -->
17. <!--                                                                      -->
18. <!--   antiClickJackingEnabled                                            -->
19. <!--                       Should the anti click-jacking header           -->
20. <!--                       X-Frame-Options be added to every response?    -->
21. <!--                       [true]                                         -->
22. <!--                                                                      -->
23. <!--   antiClickJackingOption                                             -->
24. <!--                       What value should be used for the header. Must -->
25. <!--                       be one of DENY, SAMEORIGIN, ALLOW-FROM         -->
26. <!--                       (case-insensitive). [DENY]                     -->
27. <!--                                                                      -->
28. <!--   antiClickJackingUri IF ALLOW-FROM is used, what URI should be      -->
29. <!--                       allowed? []                                    -->
30. <!--                                                                      -->
31. <!--   blockContentTypeSniffingEnabled                                    -->
32. <!--                       Should the header that blocks content type     -->
33. <!--                       sniffing be added to every response? [true]    -->
34. <!--
35. <filter>
36. <filter-name>httpHeaderSecurity</filter-name>
37. <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
38. <async-supported>true</async-supported>
39. </filter>
40. -->

<!-- ================== Built In Filter Definitions ===================== -->

  <!-- A filter that sets various security related HTTP Response headers.   -->
  <!-- This filter supports the following initialization parameters         -->
  <!-- (default values are in square brackets):                             -->
  <!--                                                                      -->
  <!--   hstsEnabled         Should the HTTP Strict Transport Security      -->
  <!--                       (HSTS) header be added to the response? See    -->
  <!--                       RFC 6797 for more information on HSTS. [true]  -->
  <!--                                                                      -->
  <!--   hstsMaxAgeSeconds   The max age value that should be used in the   -->
  <!--                       HSTS header. Negative values will be treated   -->
  <!--                       as zero. [0]                                   -->
  <!--                                                                      -->
  <!--   hstsIncludeSubDomains                                              -->
  <!--                       Should the includeSubDomains parameter be      -->
  <!--                       included in the HSTS header.                   -->
  <!--                                                                      -->
  <!--   antiClickJackingEnabled                                            -->
  <!--                       Should the anti click-jacking header           -->
  <!--                       X-Frame-Options be added to every response?    -->
  <!--                       [true]                                         -->
  <!--                                                                      -->
  <!--   antiClickJackingOption                                             -->
  <!--                       What value should be used for the header. Must -->
  <!--                       be one of DENY, SAMEORIGIN, ALLOW-FROM         -->
  <!--                       (case-insensitive). [DENY]                     -->
  <!--                                                                      -->
  <!--   antiClickJackingUri IF ALLOW-FROM is used, what URI should be      -->
  <!--                       allowed? []                                    -->
  <!--                                                                      -->
  <!--   blockContentTypeSniffingEnabled                                    -->
  <!--                       Should the header that blocks content type     -->
  <!--                       sniffing be added to every response? [true]    -->
<!--
    <filter>
        <filter-name>httpHeaderSecurity</filter-name>
        <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
        <async-supported>true</async-supported>
    </filter>
-->

于是把这个filter放入到java web的web.xml中进行测试，发现http相应头中有了关于X-Frame-Options的信息，最终经过尝试，成功的设置X-Frame-Options，如下：

1. <filter>
2. <filter-name>httpHeaderSecurity</filter-name>
3. <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
4. <async-supported>true</async-supported>
5. <init-param>
6. <param-name>antiClickJackingOption</param-name>
7. <param-value>SAMEORIGIN</param-value>
8. </init-param>
9. </filter>

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

检测报告中的修复方法还说明了开发人员还必须使用客户端 frame busting JavaScript 作为对 XFS 的保护，故又进行了相关的查询，其实就是使用JavaScript来检测页面是否是当前打开页面的最外层，如果不是，将最外层的地址换成本页面的地址，实现方法很简单，如下：

1. if (top != self) {top.location.replace(self.location.href); }

if (top != self) {top.location.replace(self.location.href); }

到此，就完成了，之前从未考虑过此方面的内容，果然，还是实际项目更加锻炼人。