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