安全測試===8大前端安全問題（上）

本文轉自：https://www.testwo.com/article/1144

當咱們說「前端安全問題」的時候，咱們在說什麼

「安全」是個很大的話題，各類安全問題的類型也是種類繁多。若是咱們把安全問題按照所發生的區域來進行分類的話，那麼全部發生在後端服務器、應用、服務當中的安全問題就是「後端安全問題」，全部發生在瀏覽器、單頁面應用、Web頁面當中的安全問題則算是「前端安全問題」。好比說，SQL注入漏洞發生在後端應用中，是後端安全問題，跨站腳本攻擊（XSS）則是前端安全問題，由於它發生在用戶的瀏覽器裏。

 

除了從安全問題發生的區域來分類以外，也能夠從另外一個維度來判斷：針對某個安全問題，團隊中的哪一個角色最適合來修復它？是後端開發仍是前端開發？

總的來講，當咱們下面在談論「前端安全問題」的時候，咱們說的是發生在瀏覽器、前端應用當中，或者一般由前端開發工程師來對其進行修復的安全問題。

8大前端安全問題

按照上面的分類辦法，咱們總結出了8大典型的前端安全問題，它們分別是：

• 老生常談的XSS

• 警戒iframe帶來的風險

• 別被點擊劫持了

• 錯誤的內容推斷

• 防火防盜防豬隊友：不安全的第三方依賴包

• 用了HTTPS也可能掉坑裏

• 本地存儲數據泄露

• 缺失靜態資源完整性校驗

因爲篇幅所限，本篇文章先給各位介紹前4個前端安全問題。

老生常談的XSS

XSS是跨站腳本攻擊（Cross-Site Scripting）的簡稱，它是個老油條了，在OWASP Web Application Top 10排行榜中長期霸榜，從未掉出過前三名。XSS這類安全問題發生的本質緣由在於，瀏覽器錯誤的將攻擊者提供的用戶輸入數據當作JavaScript腳本給執行了。

XSS有幾種不一樣的分類辦法，例如按照惡意輸入的腳本是否在應用中存儲，XSS被劃分爲「存儲型XSS」和「反射型XSS」，若是按照是否和服務器有交互，又能夠劃分爲「Server Side XSS」和「DOM based XSS」。

不管怎麼分類，XSS漏洞始終是威脅用戶的一個安全隱患。攻擊者能夠利用XSS漏洞來竊取包括用戶身份信息在內的各類敏感信息、修改Web頁面以欺騙用戶，甚至控制受害者瀏覽器，或者和其餘漏洞結合起來造成蠕蟲攻擊，等等。總之，關於XSS漏洞的利用，只有想不到沒有作不到。

 

如何防護

防護XSS最佳的作法就是對數據進行嚴格的輸出編碼，使得攻擊者提供的數據再也不被瀏覽器認爲是腳本而被誤執行。例如<script>在進行HTML編碼後變成了&lt;script&gt;，而這段數據就會被瀏覽器認爲只是一段普通的字符串，而不會被當作腳本執行了。

編碼也不是件容易的事情，須要根據輸出數據所在的上下文來進行相應的編碼。例如剛纔的例子，因爲數據將被放置於HTML元素中，所以進行的是HTML編碼，而若是數據將被放置於URL中，則須要進行URL編碼，將其變爲%3Cscript%3E。此外，還有JavaScript編碼、CSS編碼、HTML屬性編碼、JSON編碼等等。好在現現在的前端開發框架基本上都默認提供了前端輸出編碼，這大大減輕了前端開發小夥伴們的工做負擔。

其餘的防護措施，例如設置CSP HTTP Header、輸入驗證、開啓瀏覽器XSS防護等等都是可選項，緣由在於這些措施都存在被繞過的可能，並不能徹底保證能防護XSS攻擊。不過它們和輸出編碼卻能夠共同協做實施縱深防護策略。

你能夠查閱OWASP XSS Prevention Cheat Sheet，裏面有關於XSS及其防護措施的詳細說明。

警戒iframe帶來的風險

有些時候咱們的前端頁面須要用到第三方提供的頁面組件，一般會以iframe的方式引入。典型的例子是使用iframe在頁面上添加第三方提供的廣告、天氣預報、社交分享插件等等。

iframe在給咱們的頁面帶來更多豐富的內容和能力的同時，也帶來了很多的安全隱患。由於iframe中的內容是由第三方來提供的，默認狀況下他們不受咱們的控制，他們能夠在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。

若是說iframe只是有可能會給用戶體驗帶來影響，看似風險不大，那麼若是iframe中的域名由於過時而被惡意攻擊者搶注，或者第三方被黑客攻破，iframe中的內容被替換掉了，從而利用用戶瀏覽器中的安全漏洞下載安裝木馬、惡意勒索軟件等等，這問題可就大了。

如何防護

還好在HTML5中，iframe有了一個叫作sandbox的安全屬性，經過它能夠對iframe的行爲進行各類限制，充分實現「最小權限「原則。使用sandbox的最簡單的方式就是隻在iframe元素中添加上這個關鍵詞就好，就像下面這樣：

<iframe sandbox src="..."> ... </iframe> 

sandbox還忠實的實現了「Secure By Default」原則，也就是說，若是你只是添加上這個屬性而保持屬性值爲空，那麼瀏覽器將會對iframe實施史上最嚴厲的調控限制，基本上來說就是除了容許顯示靜態資源之外，其餘什麼都作不了。好比不許提交表單、不許彈窗、不許執行腳本等等，連Origin都會被強制從新分配一個惟一的值，換句話講就是iframe中的頁面訪問它本身的服務器都會被算做跨域請求。

另外，sandbox也提供了豐富的配置參數，咱們能夠進行較爲細粒度的控制。一些典型的參數以下：

• allow-forms：容許iframe中提交form表單

• allow-popups：容許iframe中彈出新的窗口或者標籤頁（例如，window.open()，showModalDialog()，target=」_blank」等等）

• allow-scripts：容許iframe中執行JavaScript

• allow-same-origin：容許iframe中的網頁開啓同源策略

更多詳細的資料，能夠參考iframe中關於sandbox的介紹。

別被點擊劫持了

有個詞叫作防不勝防，咱們在經過iframe使用別人提供的內容時，咱們本身的頁面也可能正在被不法分子放到他們精心構造的iframe或者frame當中，進行點擊劫持攻擊。

這是一種欺騙性比較強，同時也須要用戶高度參與才能完成的一種攻擊。一般的攻擊步驟是這樣的：

1. 攻擊者精心構造一個誘導用戶點擊的內容，好比Web頁面小遊戲；

2. 將咱們的頁面放入到iframe當中；

3. 利用z-index等CSS樣式將這個iframe疊加到小遊戲的垂直方向的正上方；

4. 把iframe設置爲100%透明度；

5. 受害者訪問到這個頁面後，肉眼看到的是一個小遊戲，若是受到誘導進行了點擊的話，實際上點擊到的倒是iframe中的咱們的頁面。

點擊劫持的危害在於，攻擊利用了受害者的用戶身份，在其不知情的狀況下進行一些操做。若是隻是迫使用戶關注某個微博帳號的話，看上去彷彿還能夠承受，可是若是是刪除某個重要文件記錄，或者竊取敏感信息，那麼形成的危害可就難以承受了。

如何防護

有多種防護措施均可以防止頁面遭到點擊劫持攻擊，例如Frame Breaking方案。一個推薦的防護方案是，使用X-Frame-Options：DENY這個HTTP Header來明確的告知瀏覽器，不要把當前HTTP響應中的內容在HTML Frame中顯示出來。

關於點擊劫持更多的細節，能夠查閱OWASP Clickjacking Defense Cheat Sheet。

錯誤的內容推斷

想象這樣一個攻擊場景：某網站容許用戶在評論裏上傳圖片，攻擊者在上傳圖片的時候，看似提交的是個圖片文件，實則是個含有JavaScript的腳本文件。該文件逃過了文件類型校驗（這涉及到了惡意文件上傳這個常見安全問題，可是因爲和前端相關度不高所以暫不詳細介紹），在服務器裏存儲了下來。接下來，受害者在訪問這段評論的時候，瀏覽器會去請求這個假裝成圖片的JavaScript腳本，而此時若是瀏覽器錯誤的推斷了這個響應的內容類型（MIME types），那麼就會把這個圖片文件當作JavaScript腳本執行，因而攻擊也就成功了。

問題的關鍵就在於，後端服務器在返回的響應中設置的Content-Type Header僅僅只是給瀏覽器提供當前響應內容類型的建議，而瀏覽器有可能會自做主張的根據響應中的實際內容去推斷內容的類型。

在上面的例子中，後端經過Content-Type Header建議瀏覽器按照圖片來渲染此次的HTTP響應，可是瀏覽器發現響應中實際上是JavaScript，因而就擅自作主把這段響應當作JS腳原本解釋執行，安全問題也就產生了。

如何防護

瀏覽器根據響應內容來推斷其類型，原本這是個很「智能」的功能，是瀏覽器強大的容錯能力的體現，可是卻會帶來安全風險。要避免出現這樣的安全問題，辦法就是經過設置X-Content-Type-Options這個HTTP Header明確禁止瀏覽器去推斷響應類型。

一樣是上面的攻擊場景，後端服務器返回的Content-Type建議瀏覽器按照圖片進行內容渲染，瀏覽器發現有X-Content-Type-OptionsHTTP Header的存在，而且其參數值是nosniff，所以不會再去推斷內容類型，而是強制按照圖片進行渲染，那麼由於實際上這是一段JS腳本而非真實的圖片，所以這段腳本就會被瀏覽器看成是一個已經損壞或者格式不正確的圖片來處理，而不是看成JS腳原本處理，從而最終防止了安全問題的發生。

更多關於X-Content-Type-Options的細節請參考這裏。

小結

本文對前端安全問題進行了一次梳理，介紹了其中4個典型的前端安全問題，包括它們發生的緣由以及防護辦法。在下篇文章中，咱們將介紹其餘的幾個前端安全問題，敬請期待。