老板知道會點贊，前端開發(fā)人員的10個安全建議
Web安全是前端開發(fā)人員經(jīng)常忽略的主題。當(dāng)我們評估網(wǎng)站的質(zhì)量時，我們通常會查看性能，SEO友好性和可訪問性等指標(biāo)，而網(wǎng)站抵御惡意攻擊的能力卻常常被忽略。即使敏感的用戶數(shù)據(jù)存儲在服務(wù)器端，后端開發(fā)人員也必須采取重要措施來保護服務(wù)器，但最終，保護數(shù)據(jù)的責(zé)任在后端和前端之間共享。雖然敏感數(shù)據(jù)可能被安全地鎖在后端倉庫中，但前端掌握著前門的鑰匙，竊取它們通常是獲得訪問權(quán)限的最簡單方法。
后端和前端之間共同承擔(dān)保護用戶數(shù)據(jù)的責(zé)任
惡意用戶可以采取多種攻擊手段來破壞我們的前端應(yīng)用程序，但是幸運的是，我們只需使用幾個正確配置的響應(yīng)頭并遵循良好的開發(fā)實踐，就可以在很大程度上減輕此類攻擊的風(fēng)險。在本文中，我將介紹10種簡單的操作，可以通過這些簡單的操作來改善對Web應(yīng)用程序的保護。
測量結(jié)果
在我們開始改善網(wǎng)站安全性之前，重要的一點是要對我們所做更改的有效性提供反饋。雖然量化構(gòu)成“良好開發(fā)實踐”的內(nèi)容可能比較困難，但是可以相當(dāng)準(zhǔn)確地度量安全頭的強度。就像我們使用Lighthouse獲取性能，SEO和可訪問性分數(shù)一樣，我們可以使用 SecurityHeaders.com根據(jù)當(dāng)前響應(yīng)頭獲取安全分數(shù)。
SecurityHeaders可以給我們的最高分是“A+”，我們應(yīng)該始終為此努力。
關(guān)于響應(yīng)頭的說明
處理響應(yīng)頭曾經(jīng)是后端的任務(wù)，但是如今，我們經(jīng)常將Web應(yīng)用程序部署到Zeit或Netlify等“無服務(wù)器”云平臺，并配置它們以返回正確的響應(yīng)標(biāo)頭成為前端責(zé)任。確保了解你的云托管提供商如何使用響應(yīng)頭，并進行相應(yīng)配置。
下面來看一下具體的安全措施有哪些。
1. 使用強大的內(nèi)容安全策略
完善的內(nèi)容安全策略(CSP)是前端應(yīng)用程序安全的基石。CSP是瀏覽器中引入的一種標(biāo)準(zhǔn)，用于檢測和緩解某些類型的代碼注入攻擊，包括跨站點腳本(XSS)和點擊劫持。
強CSP可以禁用可能有害的內(nèi)聯(lián)代碼執(zhí)行，并限制加載外部資源的域?？梢酝ㄟ^將 Content-Security-Policy頭設(shè)置為以分號分隔的指令列表來啟用CSP。如果你的網(wǎng)站不需要訪問任何外部資源，一個良好的頭的起始值可能是這樣的：
- Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self'; connect-src 'self';
在這里，我們將script-src、img-src、style-src 和 connect-src 指令設(shè)置為 self，以指示所有腳本、圖像、樣式表和fetch調(diào)用都應(yīng)該被限制在HTML文檔提供服務(wù)的同一來源。其他任何未明確提及的CSP指令將回退到 default-src 指令指定的值。我們將其設(shè)置為 none 表示默認行為是拒絕任何URL的連接。
然而，如今幾乎任何web應(yīng)用程序都不是獨立的，所以你可能要調(diào)整這個頭，以便你可以使用其他信任域，如域名Google Fonts或AWS S3 bucket，但始終最好從以下開始最嚴格的政策，并在需要時稍后放寬。
您可以在MDN網(wǎng)站上找到CSP指令的完整列表。
2. 啟用XSS保護模式
如果用戶輸入確實注入了惡意代碼，我們可以通過提供 "X-XSS-Protection": "1; mode = block" 頭指令來指示瀏覽器阻止響應(yīng)。
盡管大多數(shù)現(xiàn)代瀏覽器默認情況下都啟用了XSS保護模式，并且我們也可以使用內(nèi)容安全策略來禁用內(nèi)聯(lián)JavaScript，但仍建議包含 X-XSS-Protection頭，以確保不使用內(nèi)聯(lián)JavaScript的舊版瀏覽器具有更好的安全性。
3. 禁用iframe嵌入以防止點擊劫持攻擊
點擊劫持是一種攻擊，網(wǎng)站A上的用戶被誘騙對網(wǎng)站B執(zhí)行某些操作。為了實現(xiàn)這一點，惡意用戶將網(wǎng)站B嵌入到一個不可見的iframe中，然后將iframe放置在網(wǎng)站A上毫無防備的用戶的光標(biāo)之下，因此當(dāng)用戶單擊，或者更確切地說，認為他們單擊了網(wǎng)站A上的元素時，他們實際上是單擊了網(wǎng)站B上的某個東西。
我們可以通過提供 X-Frame-Options 響應(yīng)頭來防止此類攻擊，該響應(yīng)頭禁止在框架中呈現(xiàn)網(wǎng)站：
- "X-Frame-Options": "DENY"
另外，我們可以使用frame-ancestors CSP指令，該指令可以更好地控制父級可以或不能將頁面嵌入iframe的程度。
4. 限制對瀏覽器功能和API的訪問
良好的安全做法的一部分是，限制對正確使用我們的網(wǎng)站所不需要的任何內(nèi)容的訪問。我們已經(jīng)使用CSP應(yīng)用了這個原則來限制網(wǎng)站可以連接的域的數(shù)量，但是它也可以應(yīng)用到瀏覽器特性上。
我們可以使用 Feature-Policy 頭指示瀏覽器拒絕訪問我們的應(yīng)用不需要的某些功能和API。
我們將 Feature-Policy 設(shè)置為由分號分隔的一串規(guī)則，其中每個規(guī)則都是功能的名稱，后跟其策略名稱。
- "Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"
Smashing Magazine上有一篇很棒的文章，詳細介紹了功能策略，但大多數(shù)情況下，您希望為所有不使用的特性設(shè)置 none。
5. 不要泄露referrer值
當(dāng)你點擊一個鏈接，從你的網(wǎng)站導(dǎo)航，目的地網(wǎng)站將收到你的網(wǎng)站上最后一個位置的URL在一個 referrer 頭。該URL可能包含敏感數(shù)據(jù)和半敏感數(shù)據(jù)(例如會話令牌和用戶ID)，這些數(shù)據(jù)永遠都不應(yīng)公開。
為了防止referrer 值泄漏，我們將 Referrer-Policy 標(biāo)頭設(shè)置為 no-referrer ：
- "Referrer-Policy": "no-referrer"
在大多數(shù)情況下，這個值應(yīng)該是不錯的，但是如果您的應(yīng)用程序邏輯要求您在某些情況下保留 referrer，請查看Scott Helme撰寫的這篇文章，在這篇文章中，他分解了所有可能的頭值以及何時應(yīng)用它們。
6. 不要根據(jù)用戶輸入設(shè)置innerHTML值
跨站點腳本攻擊可以通過許多不同的DOM API進行，其中惡意代碼被注入到網(wǎng)站中，但是最常用的是 innerHTML。
我們永遠不應(yīng)基于用戶未過濾的輸入來設(shè)置 innerHTML。用戶可以直接操作的任何值——輸入字段中的文本、URL中的參數(shù)或本地存儲項——都應(yīng)該首先進行轉(zhuǎn)義和清除。理想情況下，使用textContent而不是innerHTML可以完全避免生成HTML輸出。如果確實需要為用戶提供富文本編輯，請使用專業(yè)的第三方庫。
不幸的是，innerHTML 并不是DOM API的唯一弱點，而且容易受到XSS注入攻擊的代碼仍然難以檢測。這就是為什么一定要有一個嚴格的不允許內(nèi)聯(lián)代碼執(zhí)行的內(nèi)容安全策略。
7. 使用UI框架
諸如React，Vue和Angular之類的現(xiàn)代UI框架內(nèi)置了良好的安全性，可以很大程度上消除XSS攻擊的風(fēng)險。它們自動對HTML輸出進行編碼，減少對XSS敏感DOM API的使用，并為潛在危險的方法(如dangerouslySetInnerHTML)提供明確而謹慎的名稱。
8. 保持你的依賴關(guān)系是最新的
快速瀏覽一下 node_modules 文件夾，就會確認我們的web應(yīng)用程序是由數(shù)百(如果不是數(shù)千)個依賴項組成的lego拼圖。確保這些依賴項不包含任何已知的安全漏洞對于網(wǎng)站的整體安全非常重要。
確保依賴關(guān)系保持安全和最新的最佳方法是使漏洞檢查成為開發(fā)過程的一部分。為此，您可以集成Dependabot和Snyk之類的工具，這些工具將為過時或潛在易受攻擊的依賴項創(chuàng)建提取請求，并幫助您更快地應(yīng)用修補程序。
9. 添加第三方服務(wù)前請三思
第三方服務(wù)如Google Analytics、Intercom、Mixpanel等，可以為您的業(yè)務(wù)需求提供“一行代碼”的解決方案。同時，它們會使你的網(wǎng)站更容易受到攻擊，因為如果第三方服務(wù)受到損害，那么你的網(wǎng)站也會受到損害。
如果你決定集成第三方服務(wù)，請確保設(shè)置最強大的CSP策略，該策略仍將允許該服務(wù)正常運行。大多數(shù)流行的服務(wù)都記錄了它們要求的CSP指令，因此請確保遵循其準(zhǔn)則。
在使用Google Tag Manager、Segment或任何其他允許組織中任何人集成更多第三方服務(wù)的工具時，應(yīng)該特別注意。有權(quán)使用此工具的人員必須了解連接其他服務(wù)的安全隱患，并且最好與開發(fā)團隊進行討論。
10. 對第三方腳本使用子資源完整性
對于您使用的所有第三方腳本，請確保在可能的情況下包括 integrity 屬性。瀏覽器具有 Subresource Integrity 功能，該功能可以驗證您正在加載的腳本的加密哈希，并確保它未被篡改。
你的 script 標(biāo)簽如下所示：
- <script src="https://example.com/example-framework.js"
- integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
- crossorigin="anonymous"></script>
值得說明的是，此技術(shù)對第三方庫有用，但對第三方服務(wù)的作用較小。大多數(shù)情況下，當(dāng)你為第三方服務(wù)添加腳本時，該腳本僅用于加載另一個從屬腳本。無法檢查依賴腳本的完整性，因為可以隨時對其進行修改，因此在這種情況下，我們必須依靠嚴格的內(nèi)容安全策略。
