最近项目要交付了,对方安全测试的时候检测出高危险漏洞,由于刚参加工作不久,经验不足,未涉及过此方面的东西。经过一番查询和探索,最终解决了这个问题,记录一下。 发现的漏洞为缺少跨框架脚本保护。跨框架脚本(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); }
到此,就完成了,之前从未考虑过此方面的内容,果然,还是实际项目更加锻炼人。
————————————————