如何預防應用程序中的XSS漏洞

04-15

什麼是XSS、如何預防它？

雖然每個人都可以很好地解釋XSS，但很少有人知道如何預防它。

當惡意攻擊者向伺服器發送一個字元串時，就會發生跨站點腳本。當該字元串會被應用到受害者的Web瀏覽器，瀏覽器就會將該字元串解釋為要執行的腳本，這樣，這些惡意腳本可以使用受害者的經過身份驗證的會話來執行許多不同的惡意操作。

目前總共有三種類型的XSS：

1.反射XSS是XSS分類中最多的，他們原理是樣的攻擊者發現存在反射XSS的URL，然後根據輸出點的環境構造XSS代碼，從而進行編碼、縮短(可有可無，是為了增加迷惑性)，最後發送給受害者，當受害者打開後，攻擊者就可以執行XSS代碼，比如獲取cookies、url、瀏覽器信息、IP等等。簡單來說反射型XSS是非持久化，需要欺騙用戶自己去點擊鏈接才能觸發XSS代碼（伺服器中沒有這樣的頁面和內容），一般容易出現在搜索頁面。

2.存儲XSS是指伺服器保留字元串並稍後在查看特定頁面時發送它，例如在公告板或名稱欄位中發布的消息。

存儲型XSS，聽名字就能猜出來是持久化數據腳本攻擊。由攻擊者輸入惡意數據保存在資料庫，再由伺服器腳本程序從資料庫中讀取數據，然後顯示在公共顯示的固定頁面上，那麼所有瀏覽該頁面的用戶都會被攻擊。由於攻擊者輸入惡意數據保存在資料庫，再由伺服器腳本程序從資料庫中讀取數據。所以大部分的存儲型XSS漏洞都是在表單提交上會發生的。比如在個人信息或發表文章等地方，加入代碼，如果沒有過濾或過濾不嚴，那麼這些代碼將儲存到伺服器中，用戶訪問該頁面的時候觸發代碼執行。這種XSS比較危險，容易造成蠕蟲，盜竊cookie等。

與反射型XSS、存儲型XSS的區別就在於xss代碼並不需要伺服器解析響應的直接參与，觸發XSS靠的是瀏覽器端的DOM解析。

3.DOM型XSS其實是一種特殊類型的反射型XSS，它是基於DOM文檔對象模型的一種漏洞。在網站頁面中有許多頁面的元素，當頁面到達瀏覽器時瀏覽器會為頁面創建一個頂級的Document object文檔對象，接著生成各個子文檔對象，每個頁面元素對應一個文檔對象，每個文檔對象包含屬性、方法和事件。可以通過JS腳本對文檔對象進行編輯從而修改頁面的元素。也就是說，客戶端的腳本程序可以通過DOM來動態修改頁面內容，從客戶端獲取DOM中的數據並在本地執行。基於這個特性，就可以利用JS腳本來實現XSS漏洞的利用。

上圖顯示的就是一個嵌入在數字證書中的XSS，我能夠用證書名稱中的XSS創建一個數字證書，這樣XSS就可以隨意繞過系統的黑名單和白名單。當管理員查看我創建的證書時，伺服器就會對該證書進行解碼，並將解碼後的字元串發送到顯示XSS的管理員網頁瀏覽器。在這種情況下，XSS是一個Rick Roll(我最喜歡的演示方式之一)，但是任何javascript都可以嵌入到這個欄位中。

如何保護XSS?

目前預防XSS有兩種主要的方法:

1.根據輸出的上下文進行編碼，這是你對預防XSS的第一道防線，其目的就是要確保任何不受信任的輸出都可以根據其所處的上下文被正確編碼或轉義。這樣做還有另外一個好處，就是可以預防HTML的注入。對於編碼規則稍有不同的上下文,如HTML數據、屬性欄位,url等，OWASP站點會有一個清單，可以列出了各種上下文以及所需的庫編碼和建議編碼。

在此，我強烈建議你使用一個適當的框架，例如Angular，來自動處理輸出編碼。

2. 內容安全策略 (CSP, Content Security Policy) 是一個附加的安全層，用於幫助檢測和緩解某些類型的攻擊，包括XSS和數據注入等攻擊。其原理就是向網路瀏覽器發送一組html標頭指令，以幫助網頁執行那些應該執行的腳本。比如，在瀏覽網頁的過程中，尤其是移動端的網頁，經常看到有很多無關的廣告，其實大部分廣告都是所在的網路劫持了網站響應的內容，並在其中植入了廣告代碼。為了防止這種情況發生，我們可以使用CSP來快速的阻止這種廣告植入。而且CSP還可以比較好的預防DOM型XSS。

不過CSP需要與輸出編碼一起工作，才能確保任何遺漏的輸出編碼將不那麼危險。雖然CSP會終止不需要的腳本，但它卻不會阻止可用於重寫頁面以進行惡意目的的HTML注入。另外，CSP起不到防止XSS注入現有腳本的作用。如果在CSP允許的javascript內使用用戶輸入，則必須非常小心地對其進行轉義和處理，更多關於CSP的信息請點此。

一些簡單的輔助保護措施

1.除了輸出編碼和CSP保護措施之外，還可以使用設置HttpOnly標誌的方法。如果你在cookie中設置了HttpOnly屬性，那麼通過js腳本將無法讀取到cookie信息，這樣能有效的防止防止XSS收集會話信息。但這種方式能防住攻擊者嗎?HttpOnly標誌可以防止cookie被「讀取」，那麼能不能防止被「寫」呢?答案是否定的，那麼這裡面就有文章可做了，因為已證明有些瀏覽器的HttpOnly標記可以被JavaScript寫入覆蓋，而這種覆蓋可能被攻擊者利用發動session fixation攻擊。

2. X-XSS-Protection也有助於在一些瀏覽器中防止某些XSS，但在某些情況下可以被繞過。

以下兩大類緩解操作應該被避免使用

1.不要以為你對對某些字元的輸入設置了黑名單，有關這些字元的所有XSS都不會起作用。所以我的建議是，不要採用這種黑名單過濾技術，即使是輔助的措施也不可以。雖然XSS黑名單技術是非常的先進，但也不可能過濾所有這些攻擊。 Web應用防護系統(Web Application Firewall, 簡稱WAF)是使用黑名單的專業產品，就連它們不能正確地執行這些操作。如果你想了解更多關於繞過xss黑名單或過濾器的更多信息，我建議你閱讀@BruteLogic的博客。

2.白名單技術，雖然OWASP和其他人都說這是一種有效的輔助緩解措施，它不但在安全性方面幾乎沒有任何幫助，反而可以在許多系統上被繞過，造成更大的安全隱患。

2.1首先如何對複雜來源的輸入進行白名單設置就是一件非常困難的事情，在數字證書中使用XSS的XSS圖像就是一個很好的例子，在這個例子中輸入過濾不能阻止XSS。數字證書被編碼，伺服器的黑名單和白名單沒有執行解碼以驗證所有內部欄位。有時，欄位必須接受一種廣泛的數據形式，進入允許XSS的系統。在其他情況下，惡意的輸入可能會從網頁前端以外的地方進入系統，比如日誌文件、文件名、機器名等等。雖然輸入過濾器對於阻止許多類型的攻擊至關重要，但它對XSS來說並不是有效的緩解方法。

2.2雖然基於上下文的適當的輸出編碼和強大的內容安全策略(CSP)將花費開發人員很長時間，但假如防止措施一旦設置好，就可以完全緩解任何XSS攻擊。不過根據我的觀察，目前大多數團隊的開發人員資源都很有限，要完成這些安全措施幾乎是不可能的。

在某些情況下，白名單可能是有效的，比如允許一些選擇性標記，比如留言板，但這些情況很少，需要額外謹慎，以確保安全完成。

2.3對輸入數據進行編碼，這就更不可行了，因為不同位置的數據會需要不同的編碼。在輸入數據的時候，你是不可能知道所有可能的輸入數據以後的用法。這就好比，在許多系統中，數據會從網頁前端以外的地方(例如日誌文件)進入系統。

關於WAF的防護效果

雖然我強烈支持使用Web應用防護系統(Web Application Firewall, 簡稱WAF) ，但WAF也採用了黑名單技術，所以也可以被繞過，不過繞過過程並不是不容易，不過這是保護XSS的輔助措施。所以我建議你不要太過於依賴它。主要的防止措施還是使用輸出編碼和CSP。

如何測試你的應用程序中的XSS?

由於防止XSS的首要措施是根據輸出的上下文進行適當的編碼，因此在測試中需要找到沒有經過任何過濾處理的輸出。在測試環境中，禁用CSP、WAF和任何輸入過濾器，通過禁用這些輔助保護，測試工具將更容易找到沒有被正確編碼的字元輸出。千萬注意，不要在真實的運行環境中進行測試，因為存儲或持久的XSS會對你瀏覽過的站點進行攻擊，另外不適當的測試還會向攻擊者透露潛在的其他問題。

目前有許多自動化工具都可以提供XSS漏洞的測試，如Burp或AppScan。AppScan是對網站等WEB應用進行安全攻擊，通過真刀真槍的攻擊，來檢查網站是否存在安全漏洞

總結

根據數據所在的上下文，使用適當的輸出編碼或WAF可以防止XSS攻擊。不過最好的預防措施是找一個可以自動為你處理輸出編碼的框架，然後把CSP作為一個強大的輔助措施。另外就是在測試正確的輸出編碼時，禁用所有的輸入過濾器，如白名單、黑名單、WAF並刪除CSP。

本文翻譯自：http://www.friendsglobal.com/xss/preventing-xss-in-your-application/ ，如若轉載，請註明原文地址： http://www.4hou.com/web/10856.html 更多內容請關注「嘶吼專業版」——Pro4hou