今年,OWASP TOP10 2017候選版在四月初釋出,前三大漏洞成因,跨網站指令碼(Cross-site scripting,XSS)依舊名列其中。在前端盛行的年代,XSS是許多前端開發者熟悉或應熟悉的議題,也更應認識相關工具運用。

相對於其他弱點來說,XSS的成因簡單易懂,對使用者的輸入資料驗證不足(甚至沒有驗證),也沒有針對輸出的內容進行轉譯,攻擊者因而得以將惡意程式碼注入網頁,或者URL等可能的輸入來源,而瀏覽了惡意程式碼頁面的使用者,就有可能被劫持會話(Session hijacking)、釣魚(Phishing)、重導至惡意網站、進行非預期之操作(像是被更改了密碼),甚至成為蠕蟲攻擊的幫兇。

在談到XSS的文件中,經常會從最基本的Reflection XSS開始介紹,通常是透過沒有驗證輸入,也沒有轉譯輸出的搜尋頁面範例,簡單地在搜尋時夾雜HTML或JavaScript,在結果頁面上示範出如何呈現原HTML頁面中沒有的iframe,或者執行JavaScript取得Session ID,因為實際上惡意的注入並沒有儲存在伺服端,伺服端上就像鏡子般將惡意程式碼反射至使用者的頁面,故稱之為反射型。

相對地,若惡意注入的程式碼儲存在伺服端,則被歸類為Stored/Persistent XSS,由於惡意程式碼被儲存下來了,每次造訪就會有重複展示的機會(像是出現在討論區、留言版、推文等),因而容易被發展XSS蠕蟲攻擊。例如,2005年發生在MySpace上,史上第一隻XSS蠕蟲Samy就是Stored/Persistent XSS;2010年,在Twitter上,曾有多人仿效而產生的各式蠕蟲,也可以歸類在Stored/Persistent XSS。

對於Reflection XSS或Stored/Persistent XSS,基本上注入的惡意程式碼,都須發送至伺服端,通過漏洞後才回傳客戶端,一種DOM-based/Local XSS則不經此管道,而是伺服端傳回有漏洞的JavaScript,而後瀏覽器執行被注入客戶端的惡意程式碼。

例如,在請求上加上#,瀏覽器會認為這是個本地端錨點,而不會將之後的字串發至伺服端,伺服端驗證在此派不上用場。在一個真實的案例〈A Twitter DomXss, a wrong fix and something more〉中,就探討這樣的狀況,我們也看到XSS的防禦對策與難度。

如何防禦XSS,以及難以處理的部份

XSS的防禦基本上,不外乎加強對使用者輸入的驗證,以及在輸出時對內容進行轉譯,在輸入驗證上有白名單與黑名單兩種方式。

在白名單的處理方式上,通常是透過規則表示式(Regular expression),限制輸入值只能有合法的字元或規則(像是字串長度),而黑名單的方式,則是限制可能的惡意字元輸入,像是在最低限度上,必須過濾<、>、"、'、&等字元,甚至是script等含有特定程式指令的字串(現代瀏覽器其實都會檢測基本XSS模式,並在察覺時封鎖執行,但開發者不該依賴瀏覽器),在輸出時,一律對這類字元轉譯。

然而,實際的情況並沒有想像中那麼單純,檢查規則可被規避。像是:改變字元大小寫、透過填充額外字元、URL編碼或使用等價字元等方式,來繞過規則表示式的檢查;而能被注入XSS的地方太多,像是URL、特定的標籤或屬性、CSS、JavaScript通訊協定、CDATA等(別相信XSS只來自於GET),在輸出過濾與轉譯上,同樣也須考慮各種惡意字元的可能性,然而,轉譯的規則也可能被規避。

〈A Twitter DomXss, a wrong fix and something more〉談到的,就是規避檢查與轉譯的例子。話說Twitter雖然使用介面上極為簡單,卻是被XSS攻擊的常客,足見XSS防護之難,就像在〈為何XSS(跨網站腳本)漏洞難改?以twitter Mikeyy六代蠕蟲說明〉(https://goo.gl/YTv7hj)中,所寫到的:「有效防範XSS之難處在於,每個網站的架構之不同,可能造成多層的字串編解碼步驟,所以如何有效處理外來(不安全)的字串,因各網站而異」。

OWASP ESAPI

充分瞭解採用技術的細節、應用程式架構與XSS原理,像是多閱讀XSS Prevention Cheat Sheet之類的文件,撰寫程式時,盡可能考慮相關可能性,可大大避免XSS。但由於攻擊模式多,運用工具也有必要。

談到OWASP Top 10及避免漏洞攻擊之程式撰寫,多半會提及OWASP ESAPI(Enterprise Security API),這個專案定義了一系列介面,並提供了預設實作,對於常見的攻擊提供了防禦方案的參考,以Java版本的實現為例,預設實作是位於org.owasp.esapi.reference套件之下,可以基於其實現來擴充改進,若要更換實作品(以及一些安全策略),可以在ESAPI.properties中進行設定。

以輸入驗證的方案為例,可以透過ESAPI.validator()取得Validator實例(預設實作為reference套件中的DefaultValidator類別),該實例可用來檢查使用者輸入的長度、根據白名單與黑名單進行驗證、以及同義字的轉換,而白名單的根據是定義在validation.properties中的規則表示式。

除了基本的isValidInput、getValidInput方法之外,Validator也提供了像是getValidSafeHTML、getValidRedirectLocation之類的方法,在HTML等的驗證上,必須提供驗證規則來源,可以先使用antisamy-esapi.xml,其中就提供了幾百條預設規則,可見規則資料庫之重要性。

事實上,AntiSamy也是OWASP的專案,想要取得更多規則,可查看AntiSamy的專案頁面(https://goo.gl/VqY4Nt),開發者也可查看antisamy-ebay.xml、antisamy-myspace.xml等,確認定義的規則。

在輸出的過濾與轉譯方式上,我們現在可透過ESAPI.encoder()取得Encode實例(預設實作為reference套件中的DefaultEncoder類別),因為它在此提供了encodeForHTML、encodeForCSS、encodeForJavaScript、encodeForURL等方法。實際上,它也提供encodeForSQL方法,可作為基本的SQL Injecton防禦對策。

不過,在OWASP ESAPI的下載頁面中,可以看到的版本目前是2.1.0.1,然而,實際上存在著ESAPI 3.x的規劃,在Github上,2.x其實是被命名為esapi-java-legacy,只是由於缺少志願貢獻者的情況下,3.x處於停擺狀態,反而是esapi-java-legacy仍持續有提交記錄,造就2.x雖為legacy,卻比3.x還活躍的狀態(實際上,ESAPI除了Java、JavaScript之外,其他語言的實作也屬於停擺狀態)。

認識相關工具的必要

儘管XSS主要發生在前端,實際上屬於注入攻擊(Injection flaw),因此,一些防護概念也可套用在SQL Injection、重導、Expression Language Injection等注入式的攻擊裏,而XSS也容易結合其他攻擊模式(像是CSRF)而變化,所以,單憑開發者對安全的認知加強與攻擊模式的想像,不足以應對。

儘管OWASP ESAPI維護上緩慢,仍不失為一個參考方案(特別是開發者從未試著使用這類程式庫來實作安全的情況),在OWASP TOP10 2017中,仍建議了ESAPI。若想要有個不錯的文件起點,可以參考〈The OWASP Top Ten and ESAPI〉。

然而,OWASP ESAPI維護上的問題,就有可能在漏洞發生時,導致修補相對緩慢。在OWASP ESAPI官方上有個〈Should I use ESAPI?〉也讓開發者自問是否想運用ESAPI,並提供幾個更為活躍的替代子專案,像是OWASP Java Encoder Project、OWASP Java HTML Sanitizer等。

ESAPI的貢獻者之一,也在〈ESAPI No Longer an OWASP Flagship Project〉談到,ESAPI是時候該交棒給這些候選子專案了。

有機會的話,可以進一步瞭解這些工具甚至是原始碼的實現方式,也許最後未必會應用這些工具,但在這個過程中,也能學習與瞭解到,在建構安全的知識體系時,有哪些是必要的特性,以及實作上的各種考量。

作者簡介


Advertisement

更多 iThome相關內容