最近專案要交付了,對方安全測試的時候檢測出高危險漏洞,由於剛參加工作不久,經驗不足,未涉及過此方面的東西。經過一番查詢和探索,最終解決了這個問題,記錄一下。 發現的漏洞為缺少跨框架指令碼保護。跨框架指令碼(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); }
到此,就完成了,之前從未考慮過此方面的內容,果然,還是實際專案更加鍛鍊人。