◆高 巖 保永武
(武漢虹旭信息技術(shù)有限責任公司 湖北 430000)
跨站腳本攻擊(Cross-Site Scripting,XSS)在 OWASP TOP10-2017中被列為了第三威脅漏洞,僅次于注入和失效的身份認證和會話管理。成為近年來出現(xiàn)頻率最高的Web漏洞之一,跨站腳本攻擊具有攻擊范圍廣泛,跨平臺,破壞力強等特性受到攻擊者的重視;并且由于開發(fā)者以及用戶對跨站攻擊的防范意識的缺乏,很多開發(fā)人員在web開發(fā)過程中沒有意識到跨站腳本漏洞的危害,導(dǎo)致跨站腳本漏洞被忽視。
現(xiàn)有的防御措施大多數(shù)依靠服務(wù)端純文本過濾來實現(xiàn),但服務(wù)端純文本過濾存在許多問題:首先是設(shè)定黑名單時很難全面包含所有惡意函數(shù),無法正確地涵蓋所有標簽以及屬性,攻擊者可以利用黑名單外的標簽構(gòu)造惡意代碼進行攻擊;其次是白名單的使用可以有效地阻止跨站腳本攻擊,但會極大地影響用戶體驗,導(dǎo)致用戶輸入的非惡意數(shù)據(jù)被過濾;然后是無法完全匹配瀏覽器特性,如“svg/onload”適用于Chrome瀏覽器,但不適用于IE瀏覽器;另外針對DOM型XSS攻擊防御效果不理想。
跨站腳本攻擊發(fā)生在目標網(wǎng)站中目標用戶的瀏覽器層面上,在用戶瀏覽器渲染整個 HTML文檔的過程中出現(xiàn)腳本指令控制用戶瀏覽器進行攻擊。
通常,根據(jù)XSS攻擊的攻擊方式以及利用手法不同,將跨站腳本分為三類:反射型XSS、存儲型XSS、DOM型XSS。
反射型跨站腳本攻擊的注入點通常存在于網(wǎng)頁的 URL中,主要實現(xiàn)方式是通過修改 URL地址內(nèi)的參數(shù),將惡意腳本作為輸入提交到服務(wù)端。由于服務(wù)端未對跨站腳本進行完全過濾就直接返回至客戶端,在瀏覽器響應(yīng)內(nèi)容中出現(xiàn)這段跨站腳本并在瀏覽器上執(zhí)行,從而使用戶受到攻擊。反射型跨站攻擊具有實現(xiàn)難度較低、攻擊及時的特點,因此大多數(shù)跨站腳本攻擊案例為反射型跨站攻擊。在反射型跨站攻擊過程中,攻擊者通常利用精心構(gòu)造的惡意代碼進行釣魚,攻擊者通過通信工具發(fā)送包含攻擊代碼的URL給受害者,當受害者點擊攻擊者構(gòu)造的URL時會觸發(fā)攻擊者構(gòu)造的攻擊代碼,然后向服務(wù)端發(fā)出請求,服務(wù)端響應(yīng)后返回給受害者瀏覽器,攻擊代碼得以順利執(zhí)行,攻擊行為完成。
存儲型跨站腳本攻擊與反射型跨站腳本攻擊最明顯的差別在于攻擊者精心構(gòu)造的跨站腳本會存儲在服務(wù)端(服務(wù)端的數(shù)據(jù)庫或者文件系統(tǒng)中),攻擊者再次請求該頁面時不需要再次提交跨站腳本。反射型跨站腳本攻擊的注入點通常存在于 URL中,存儲型跨站腳本攻擊的注入點一般出現(xiàn)在有交互功能的地方,如網(wǎng)站的留言板、評論區(qū)、博客日志、個人信息等??缯灸_本被存儲到服務(wù)端,當其他用戶或管理員瀏覽該信息時,瀏覽器將會直接從服務(wù)端讀取攻擊者構(gòu)造的跨站腳本,并在瀏覽器執(zhí)行該跨站腳本。
DOM型XSS不同于上述提到的反射型XSS以及存儲型XSS,DOM型XSS取決于輸出位置,而不取決于輸出環(huán)境。其輸出點在DOM中,DOM型XSS是從JavaScript中輸出數(shù)據(jù)到HTML頁面的。因此DOM型XSS既有可能是反射型XSS,也有可能是存儲型XSS。DOM型XSS在服務(wù)端處理后的代碼輸出到頁面后,可能會再次經(jīng)過客戶端腳本處理后輸出,因此僅僅在服務(wù)端部署防御是無法過濾DOM型XSS的。
傳統(tǒng)的協(xié)同過濾(圖1)是將非信任數(shù)據(jù)先進行客戶端過濾,然后進行服務(wù)端過濾,最后輸出到客戶端的瀏覽器進行解析。攻擊者可以利用抓包軟件對HTTP數(shù)據(jù)包進行攔截并修改從而繞過客戶端過濾,導(dǎo)致客戶端過濾失效。針對此種攻擊,本文設(shè)計了一套更為完善的客戶端與服務(wù)端協(xié)同過濾體系,在服務(wù)端進行過濾后再通過客戶端對代碼進行過濾,過濾流程如圖2所示。該方法相對于純服務(wù)端過濾而言,可以減少服務(wù)端的壓力的同時有效防止DOM型跨站腳本攻擊,比純客戶端過濾在防范非DOM型跨站腳本攻擊中的效果更好。該方法不僅具有傳統(tǒng)的協(xié)同過濾的優(yōu)點,而且可以防范攻擊者通過抓取HTTP并修改的方式繞過客戶端過濾,更好地針對跨站腳本攻擊進行防御。
圖1 傳統(tǒng)跨站腳本過濾流程圖
通常攻擊者想要利用XSS漏洞進行攻擊,需要將網(wǎng)頁中的標簽閉合掉(如”
圖2 改進后的跨站腳本過濾流程圖
對于敏感字符的處理,本文通過相應(yīng)的符號對其進行替換。首先對輸入的非信任數(shù)據(jù)進行遍歷,判斷數(shù)據(jù)中的每個字符串是否包含前文所規(guī)定的敏感字符,若是敏感字符則對其進行替換。如表1所示。
表1 敏感字符替換表
經(jīng)過上述操作,可完成對敏感字符的替換,破壞攻擊者所構(gòu)造的代碼。將過濾后的代碼輸出至客戶端,由客戶端過濾系統(tǒng)完成后續(xù)過濾。
服務(wù)端通過對敏感字符進行替換的防御方式主要對非 DOM型跨站腳本過濾,但由于DOM型XSS的特性導(dǎo)致純服務(wù)端過濾并不能完全過濾跨站腳本,因此,針對DOM型XSS攻擊的防御將在客戶端進行部署。防御成功時可以通過查看頁面元素看到攻擊代碼以腳本的形式輸出,但是攻擊代碼并未執(zhí)行。過濾流程圖如圖3所示。
圖3 客戶端過濾流程圖
(1)內(nèi)聯(lián)函數(shù)處理
內(nèi)聯(lián)函數(shù)是攻擊者常用的跨站腳本攻擊,本文對所有內(nèi)聯(lián)函數(shù)進行攔截,采用監(jiān)聽document對象的方法。因為所有的on事件對應(yīng)的都是“document.on******”這類屬性,所以直接遍歷document對象即可獲得所有on事件,并對所有on事件進行攔截。提取on事件的屬性值,并對on事件的屬性值與黑名單進行正則匹配。若存在于黑名單中,則刪除on事件并向后臺發(fā)送警報。
(2)靜態(tài)腳本處理
使用MutationObserve函數(shù)監(jiān)聽DOM樹中子節(jié)點和屬性的變動。當DOM節(jié)點或?qū)傩园l(fā)生變動時對其進行攔截后進行過濾處理。在過濾處理中對iframe標簽以及script標簽進行掃描,判斷標簽中是否含有src屬性,并對src屬性采取白名單匹配,若存在于白名單中則認定為非惡意輸入。
(3)動態(tài)腳本處理
針對腳本是動態(tài)生成的,因此需要在腳本插入DOM樹前捕獲腳本,并過濾惡意腳本,而MutationObserve方法只能監(jiān)聽DOM中子節(jié)點的變動,無法在腳本執(zhí)行之前過濾腳本。因此,需要對動態(tài)生成的腳本做采取以下措施:攔截動態(tài)生成的 src以及innerHTML屬性、重寫document.write屬性、重寫setattribute屬性、重寫Ajax請求、重寫Websocket請求、重寫postMessage請求。
在系統(tǒng)整體功能測試中,需要在服務(wù)端引入JSP編寫的防御模塊進行服務(wù)端的跨站腳本防御,并在服務(wù)端向客戶端輸出過程中引入 JavaScript編寫的防御模塊進行客戶端跨站腳本防御。最終起到協(xié)同防御效果。
在系統(tǒng)測試中,本文將該防御系統(tǒng)部署在帶有輸入功能的留言板中,對留言板進行模擬攻擊測試。選取跨站攻擊腳本:
提交后頁面源代碼對應(yīng)的腳本如下:
</textarea><input onload=alert(1)>
可以看到半角的”<”被替換成全角的” <”導(dǎo)致攻擊腳本以文本的形式輸出,無法執(zhí)行腳本。證明了服務(wù)端過濾的有效性。
為了證明客戶端過濾的有效性,在此僅僅部署客戶端防御模塊,對留言板進行模擬攻擊測試。用同樣的攻擊代碼進行測試,提交后觀察頁面源代碼對應(yīng)腳本如下:
代碼以腳本的形式輸出,但是”alert”并未執(zhí)行。通過瀏覽器控制器可以看到攻擊腳本被客戶端攔截,證明了客戶端過濾的有效性。
隨著Web應(yīng)用的功能越來越全面,人們對Web應(yīng)用越來越依賴,隨之而來的 Web安全問題也越來越嚴重。跨站腳本攻擊是一種非常常見的web攻擊,跨站腳本攻擊的防御是如今網(wǎng)絡(luò)安全研究的熱點 。本文提出的客戶端與服務(wù)端協(xié)同防御跨站腳本攻擊系統(tǒng)中,使用JavaScript語言編寫適用于主流瀏覽器??蓪缯灸_本攻擊進行有效過濾的同時減輕服務(wù)端壓力。
[1]OWASP Top Ten project for 2017 [EB/OL].http://www.owasp.org.cn/owasp-project/ 2017-owasp-top-10,2017.
[2]邱永華.XSS跨站腳本攻擊剖析與防御[M].人民郵電出版社,2013.
[3]吳翰清.白帽子講Web安全[M].電子工業(yè)出版社,2012.