關於前端的 13 個安全提示

時間 2020-05-13

原文原文鏈接

做者：Deepak Gupta
翻譯：瘋狂的技術宅javascript

原文：https://medium.com/better-pro...html

未經容許嚴禁轉載前端

不管你是 React.js、Angular、Vue.js 程序員仍是前端頁面仔，你的代碼均可以成爲引誘黑客入侵的大門。java

做爲前端開發人員，咱們最關心的是性能、SEO 和 UI/UX——安全性卻常常被忽略。react

你可能會驚訝地知道大型框架如何使你的網站對跨站點腳本（XSS）攻擊打開大門。有不少危險的操做，例如 React 中的 dangerouslySetInnerHTML 或 Angular 中的 bypassSecurityTrust API。程序員

咱們應該記住，就安全性而言，前端如今與後端或 DevOps 承擔着一樣的責任。前端可能會發生幾千種惡意攻擊。web

先讓咱們瞭解一些常見的狀況——將涵蓋這類攻擊中的很大一部分。面試

1. 不受限制的文件上傳

這是一種將惡意文件上傳到服務器而後對系統執行的攻擊方式。攻擊可能包括：使文件系統或數據庫超載，接管完整的系統，客戶端攻擊，將攻擊轉發到後端系統或進行簡單的破壞。數據庫

2. 點擊劫持

這是一種惡意用戶誘騙正經常使用戶點擊網頁或不屬於該站點的元素的攻擊方式。這種攻擊可能會致使用戶在不經意間提供憑據或敏感信息、下載惡意軟件、訪問惡意網頁、在線購買產品或轉移資金。npm

3. XSS 攻擊

這是一種將惡意腳本以瀏覽器端腳本的形式注入網頁的攻擊方式。網站上的缺陷使這些攻擊普遍傳播並得以成功。

4. SQL注入

這是一種經過輸入字段把惡意代碼注入到 SQL 語句中去破壞數據庫的攻擊方式。

5. 拒絕服務攻擊（ DoS 攻擊）

這種攻擊方式經過用流量轟炸服務器，使目標用戶沒法使用服務器或其資源。

6. 中間人攻擊或會話劫持

這種攻擊方式依靠攔截客戶端與服務器之間的通訊，以竊取密碼、賬號或其餘我的詳細信息。

攻擊者一直試圖在前端發現一些漏洞，並侵入到服務器中。在本文中，咱們將看到前端編碼時要牢記的一些常見的準則。

1.嚴格的用戶輸入（第一個攻擊點）

用戶輸入在本質上應始終保持嚴格，以免諸如 SQL 注入，點擊劫持等漏洞。因此在將用戶輸入發送到後端以前，應該先對其進行驗證或清理是很是重要的。

能夠經過刪除或替換上下文相關的危險字符來對數據進行清理，例如使用白名單並對輸入數據進行轉義。

可是，我意識到對於目前全部的可能性，清理和編碼並非一件容易的事，因此可使用如下開源庫：

DOMPurify 使用起來最簡單，只須要有一個方法就能夠清除用戶的輸入。它有自定義規則的選項，而且支持HTML五、SVG 和 MathML。
secure-filters 是 Salesforce 開發的一個庫，其中提供了清理 HTML、JavaScript、內聯 CSS 樣式和其餘上下文的方法。若是你想在某些地方使用用戶輸入的信息，例如生成 CSS 或 JavaScript 時，特別有用。

若是是文件上傳，請務必檢查文件類型並啓用文件過濾器，而且只容許某些類型的文件上傳。有關更多信息，請參考這裏：https://owasp.org/www-communi...。

2. 小心隱藏字段或存儲在瀏覽器內存中的數據

若是你打算經過 input 的 type="hidden" 把敏感數據隱藏在頁面中或把它添加到瀏覽器的 localStorage，sessionStorage，cookies 中，而且認爲這是安全的，則須要從新考慮你的解決方案。

攻擊者能夠輕鬆的訪問添加到瀏覽器中的全部內容。攻擊者能夠打開 dev tools 並更改全部內存變量。若是你根據 localStorage、 sessionStorage 和 cookies 值隱藏了身份驗證頁面，會怎麼樣？

瀏覽器中有 ZapProxy 之類的工具，甚至是一些檢查工具，它們能夠在攻擊者找到注入腳本的方法後把這些值暴露出來，而後攻擊者就能夠利用它們進一步的攻擊。

所以要避免使用 type="hidden"，以及避免把密鑰、auth token 等過多地存儲在瀏覽器的內存中。

3. 使用強大的內容安全策略（CSP）

永遠不要信任服務器發送的「任何東西」，始終都要定義一個強大的 Content-Security-Policy HTTP 頭，該標頭僅容許某些受信任的內容在瀏覽器上執行或提供更多資源。

最好有一個白名單——容許的來源清單。即便攻擊者注入了腳本，該腳本也不會與白名單匹配，更不會執行。

例如：

content-security-policy: script-src ‘self’ https://apis.xyz.com

在這裏，應用程序僅信任來自 apis.xyz.com 和咱們本身（self）的腳本。對於其他的來源，在控制檯中將會引起錯誤。

注意：強大的內容安全策略不能解決內聯腳本執行的問題，所以 XSS 攻擊仍然有效。

你能夠在 MDN 上查閱 CSP 指令的完整列表。

4. 啓用 XSS 保護模式

若是攻擊者以某種方式從用戶輸入中注入了惡意代碼，咱們能夠經過 "X-XSS-Protection": "1; mode=block" 標頭來指示瀏覽器阻止響應。

大多數現代瀏覽器默認狀況下都啓用了 XSS 保護模式，但仍建議你添加 X-XSS-Protection 標頭。這有助於確保不支持 CSP 標頭的舊版瀏覽器的安全性。

5. 避免典型的 XSS 錯誤

XSS 攻擊一般可追溯到 DOM API 的 innerHTML。例如：

document.querySelector('.tagline').innerHTML = nameFromQueryString

任何攻擊者均可以用上面的代碼行注入惡意代碼。

考慮使用 textContent 而不是 innerHTML，以防止徹底生成 HTML 輸出。若是你不生成 HTML，則沒法插入 JavaScript，也許你會看到其中的內容，但什麼事也不會發生。

請密切注意最新的受信任的類型規範，以防止藉助 google 進行基於 DOM 的跨站點腳本攻擊。

就 react.js 而言，應該對 dangerouslySetInnerHTML 保持謹慎的，而且能夠產生與 innerHTML 相似的影響。

注意：切勿基於用戶輸入去設置 innerHTML 的值，而應該儘量用 textContent 代替 innerHTML。

一樣，應正確設置 HTTP 響應頭 Content-Type 和 X-Content-Type-Options 及其預期行爲。例如不要把 JSON 數據編碼爲 text/HTML，以防止被意外執行。

6. 禁用 iframe 嵌入

禁用 iframe 可使咱們免受 clickjacking 攻擊的影響。咱們應始終在請求中使用 "X-Frame-Options"："DENY" 標頭，以禁止在框架中渲染網站。

另外，咱們能夠用 frame-ancestors CSP 指令，該指令能夠更好地控制哪些站點能夠將頁面嵌入到 iframe 中。

7. 使用模棱兩可的錯誤提示

諸如「你的密碼不正確」之類的錯誤可能不只對用戶有用，對攻擊者一樣有幫助。他們可能會從這些錯誤中找出信息，從而幫助他們計劃下一步的行動。

在處理賬戶、電子郵件和 PII 時，咱們應該嘗試使用諸如「錯誤的登陸信息」之類的模棱兩可的錯誤提示。

8. 使用驗證碼

在面向公衆的端點（登陸、註冊、聯繫）上使用驗證碼。驗證碼是一種旨在區分人與機器人的系統，能夠幫助阻止DoS（拒絕服務）攻擊。

9. 始終設置 `Referrer-Policy`

每當咱們用定位標記或導航到離開網站的連接時，請確保你使用標頭策略"Referrer-Policy": "no-referrer" ，或者在使用定位標記的狀況下，設置 rel = noopener 或 noreferrer。

若是不設置這些標頭和相關性，則目標網站能夠得到會話 token 和數據庫 ID 之類的數據。

10. 對瀏覽器功能和 API 進行限制

與 CSP 中同樣，受限域能夠鏈接到網站，一樣的原理也能夠應用於瀏覽器功能和 API。咱們能夠添加一個 Feature-Policy 標頭來拒絕對某些功能和 API 的訪問。更多內容。

提示：把全部你不用的功能設置爲 none

11. 按期審覈依賴性

按期運行 npm audit 以獲取易受攻擊軟件包的列表，並對其進行升級避免安全問題。

如今 GitHub 對易受攻擊的依賴項進行標記。還能夠用Snyk來自動檢查你的源代碼並拉取 bump 版本。

12. 分隔你的應用程序

與後端同樣，前端也可使用微服務架構，其中單個應用被拆分爲較小的自包含組件，每一個組件都單獨運行。

相同的原理也能夠應用於前端。例如一個應用能夠分爲公共部分，身份驗證部分和管理部分，每一個部分都託管在單獨的子域中，例如 https://public.example.com, https://users.example.com 和 https://admin.example.com 。

這樣能夠確保減小客戶端漏洞。

注意：適當的分隔還能夠防止應用的公共部分出現 XSS 漏洞，從而防止它自動破壞用戶信息。

13. 避免使用第三方服務

Google Analytics、Google Tag Manager、Intercom、Mixpanel 等第三方服務可能會使你的 Web 應用容易受到攻擊。想想假如這些第三方服務受到損害時會怎樣。

制定強有力的 CSP 政策很是重要。大多數第三方服務都有定義的 CSP 指令，因此請務必添加它們。

另外在添加腳本標籤時，要確保在可能的狀況下包含 integrity 屬性。 Subresource Integrity 功能能夠驗證腳本的加密哈希，並確保沒有對其進行過篡改。

<script src= "https://example.com/example-framework.js" integrity= "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..." crossorigin= "anonymous" ></script>