最近项目要交付了，对方安全测试的时候检测出高危险漏洞，由于刚参加工作不久，经验不足，未涉及过此方面的东西。经过一番查询和探索，最终解决了这个问题，记录一下。 发现的漏洞为缺少跨框架脚本保护。跨框架脚本(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，如下
<!-- ================== 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，如下：
<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来检测页面是否是当前打开页面的最外层，如果不是，将最外层的地址换成本页面的地址，实现方法很简单，如下：
if (top != self) {top.location.replace(self.location.href); }
到此，就完成了，之前从未考虑过此方面的内容，果然，还是实际项目更加锻炼人。
————————————————
版权声明：本文为CSDN博主「Jafeyyu」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u011121146/article/details/52872143
