怎么防范XSS攻擊

這篇文章主要為大家展示了“怎么防范XSS攻擊”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“怎么防范XSS攻擊”這篇文章吧。

跨站腳本是應用程序安全開源基金會 (OWASP) 前 10 名中第二個最普遍的問題——它存在于大約 2/3 的所有應用程序中。雖然自動化工具可以發現其中的一些問題，但也有一些旨在檢測和利用這些漏洞的自動化工具。

什么是跨站腳本？

當數據通過不受信任的來源（如 Web 請求）進入 Web 應用程序并未經驗證就發送給用戶時，就會發生 XSS 攻擊。

XSS 會導致腳本在用戶的瀏覽器中執行，從而導致會話被劫持、網站篡改以及將用戶重定向到惡意站點。

從本質上講，攻擊者將惡意代碼輸入到用戶輸入的部分中，服務器希望該部分是數據（但實際上是為了執行而設計的代碼）。

如果處理不當，惡意代碼可能會突破“數據平面”并作為正常代碼（“控制平面”）執行。

我們可以將大多數 XSS 攻擊分為兩類：存儲的和反射的。第三種不太常見，稱為基于 DOM 的 XSS。

當數據通過不受信任的來源進入并發送給用戶（在動態內容中）而沒有檢查惡意內容時，就會發生任何 XSS 攻擊。惡意內容可以是 JavaScript、Flash、HTML 或瀏覽器能夠執行的任何其他代碼。

反射型 XSS（影響：中等）

這是最基本的 XSS 類型，其中應用程序接收數據，然后以不安全的方式將這些數據包含在對用戶的響應中。

例如，如果攻擊者說服用戶單擊此網絡釣魚鏈接：

http://legitwebsite.com/message=<script>惡意代碼</script>

如果合法站點不處理數據而只是將其返回給用戶，則用戶的瀏覽器將執行惡意代碼。

存儲型 XSS（影響：嚴重）

當注入永久存儲在目標的服務器上時，就會發生存儲型 XSS，例如論壇或評論部分、數據庫中的消息等。從本質上講，這意味著該漏洞會影響站點/應用程序的每個訪問者。

例如，如果站點允許用戶發表評論，然后顯示他們的評論，則用戶可以輸入以下內容：

<p><script>惡意代碼</script></p>

如果站點沒有適當地檢查用戶輸入，則可能會導致腳本為看到此消息的任何其他用戶執行。

基于DOM的XSS/客戶端XSS（影響：中等）

反射型 XSS 和存儲型 XSS 與基于 DOM 的最大區別在于攻擊的注入位置。

反射和存儲 XSS 是服務器端問題，而基于 DOM 是客戶端（瀏覽器）端問題。基于 DOM 的 XSS 發生在 DOM（文檔對象模型）中，而不是作為 HTML 的一部分。

這種攻擊不是在頁面中插入惡意代碼，而是允許加載合法頁面，然后利用用戶輸入向頁面添加 HTML，執行惡意腳本。這利用了客戶端生成的 HTML 數量不斷增加的優勢。

例如，攻擊者可以通過社會工程使受害者點擊惡意鏈接（例如 http://www.legitimatewebsite.com/contact#<script>malicious code</script>）。該網站將收到對該頁面的合法請求，但不會收到惡意片段（因為瀏覽器不會向站點的服務器發送 # 字符后的任何內容）。受害者會看到合法網站，但受害者的瀏覽器也會執行惡意腳本。

由于這種攻擊的工作方式，服務器端保護不會阻止它，因為惡意代碼根本沒有發送到服務器。

相反，防止這種攻擊需要確保 JavaScript 不會以不安全的方式解釋 URI 片段（統一資源標識符 - URI 標識指定位置的資源，例如 URL）。

XSS 攻擊的緩解措施

有效緩解 XSS 攻擊需要結合以下措施，當您將它們結合使用時，可以提供強大的 XSS 防御。

避免在指定位置以外的任何地方插入用戶提供的/不受信任的數據

這是第一個也是最重要的規則。編碼、轉義、驗證和過濾輸入極其困難且非常復雜。

限制某人可以輸入不可信數據的位置要容易得多。最安全的假設是所有不受信任的數據都是惡意的。

驗證/過濾輸入

理想情況下，所有輸入都應根據可接受的值列表進行驗證。

編碼輸出

任何用戶輸入的數據都應該被編碼以防止它被讀取為活動的。這可能需要 CSS、JavaScript、URL 和/或 HTML 編碼。

確保輸出在任何暴露的點都被編碼尤為重要，因為相同的數據可以存儲并顯示在多個位置。

謹慎選擇框架

使用提供自動轉義功能的框架（如 Go 模板）或具有針對 XSS 的本機防御（如 .NET 的請求驗證）的框架。

設置 HttpOnly 標志

XSS 攻擊通常使用 JavaScript 來竊取會話 cookie（而普通的 Web 應用程序很少需要使用 JavaScript 來訪問會話 cookie）。因此，設置 HttpOnly 標志可以保護會話 cookie 免受攻擊者的攻擊，同時不會限制正常行為。大多數瀏覽器都支持設置這個標志。

使用響應頭

與 HttpOnly 標志類似，任何不應包含 HTML 或 JavaScript 的 HTTP 響應都可以利用“Content-Type”和“X-Content-Type-Options”標頭來確保瀏覽器僅以預期的方式解釋響應。

對開發人員進行安全教育

專門針對開發人員的教育，例如將應用程序安全團隊成員與開發人員配對的“安全冠軍”計劃，很重要。它們可以幫助開發人員了解安全漏洞（如 XSS）以及如何防止它們。

制定內容安全政策

內容安全策略 (CSP) 可以幫助您檢測和緩解 XSS 和其他數據注入攻擊。

他們為受信任內容的來源設置了許可名單，并且只能應用于敏感頁面（如支付頁面），或者理想情況下，應用于整個網站。如果內容是從不應加載的頁面加載的，他們甚至可以提供通知。

它們相當容易部署 - 只需將 Content-Security-Policy HTTP 標頭添加到網頁和任何適當的指令即可。

該CSP提琴手擴展可以幫助您生成一個基準CSP。該工具將圍繞瀏覽器提交的報告構建策略，創建可更改的基線策略。

此外，您可以使用由 Troy Hunt 和 Scott Helme 運行的Report URI來獲取有關 CSP 違規的警報，以便更主動地監控您的站點。

通常，策略由一系列指令組成，這些指令將描述一種資源或區域的策略。這些指令之一，子資源完整性檢查，用于確保瀏覽器驗證第三方內容（來自 CDN 之類的來源）是在沒有被操縱的情況下交付的。

本質上，提供的加密哈希必須與加載的文件匹配。如果黑客修改了第三方的內容，該站點將不會加載惡意內容。

問題是，如果內容提供者更新文件或進行合法更改，內容也不會加載（因為哈希值已更改）。

解決此問題的主要方法是利用版本化的 JavaScript 資源，例如 chatbot_0.1.23.js，而不是 chatbot.js。這是一般的最佳實踐，也保證了JS文件發生變化時服務的連續性。

雖然瀏覽器并不普遍支持此功能，但對于那些缺少該功能的瀏覽器，使用它不會破壞站點（它只是不會利用該技術）。

以上是“怎么防范XSS攻擊”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！