本博文翻譯自：
https://dotnetcoretutorials.com/2017/10/25/owasp-top-10-asp-net-core-cross-site-scripting-xss/

在這篇文章的前幾次迭代中，我用了一個很長的篇幅解釋了什么是跨站腳本(XSS)。但在花了好幾個小時來完善它之后，我覺得向你展示一個簡單的屏幕截圖就更容易了。

這例子很簡單。我有一個用戶的“搜索”頁面，并且他們輸入的任何查詢都以“搜索查詢{您的查詢在這里}”的形式回傳給他們。代碼如下所示：

<h2>Search Results for "@Html.Raw(Context.Request.Query["query"])"</h2>

因此，我們要把用戶搜索的東西(或者輸入用來查詢的字符串)，直接放到頁面上。這樣用戶就可以輸入腳本標簽，或者任何他們想要的東西。這本質上是XSS的核心。獲取未經驗證的用戶輸入，并在網頁上批量顯示。

在這篇文章中，我將引用“我之前編寫的代碼”。這個代碼在Github上，如果你想看一下，自己測試一下XSS。你可以在這里下載。

什么是XSS？

XSS是指跨站腳本攻擊它能讓攻擊者將客戶端腳本（通常為JavaScript，盡管可能有其他類型的注入）注入到網頁上，然后再向其他用戶顯示。通常這些腳本試圖竊取私人數據（例如cookies或瀏覽器存儲），重定向瀏覽器，或者有時甚至欺騙用戶進行他們通常不會做的動作。

XSS通常被定義為兩種不同的類型：

反射性XSS

反射性XSS是指在用戶輸入結果時立即發生跨站點腳本攻擊。例如，當用戶搜索時，該搜索查詢就會立即顯示在頁面上。通常，XSS的危險來自于將鏈接發送給不知情的用戶，而用戶看到的是全出乎意料的頁面。

存儲式XSS

存儲式XSS是指把惡意腳本存儲到被攻擊者的網站的數據庫。其他人訪問數據庫中的惡意腳本代碼后，瀏覽器執行惡意腳本，被攻擊。如果我們使用一個博客的例子,接受評論文章。如果您能夠在博客評論中存儲XSS漏洞，那么從那時起查看該博客文章的所有人都將受到影響。很明顯，這有可能比反射性XSS漏洞要大得多，因為它不依賴于用戶發送一個不可靠的鏈接，也不需要在他們的部分做任何額外的事情。

有人可以用XSS做什么？

使用Javascript

當然，要是能夠在網頁上注入腳本標簽。世界真的是攻擊者砧板上的肉。他們可以做一些簡單的事情，比如將用戶重定向到不同的頁面(然后他們竊取用戶的憑證)，他們可以在頁面上插入javascript來構建一個虛假的登錄表單(然后他們竊取用戶的憑證)，或者他們甚至可以用它來盜取用戶的登錄cookie(然后他們竊取用戶的憑證)。這可能是毀滅性的。

雖然在頁面上注入javascript完全是毀滅性的，但是保護你的站點不僅僅是不允許在任何地方提交“script”這個詞。實際上，你可以在沒有CSS的情況下做一些相當危險的事情。

CSS

通過向頁面中注入樣式，攻擊者可以改變頁面的整個布局來欺騙用戶做他們不想做的事情。我之前看到的一個“巧妙”漏洞是攻擊者重新設計了一個頁面，通過移動刪除按鈕并更改文本（現在可以添加CSS中的“內容”）來欺騙用戶刪除自己的帳戶。

單獨使用CSS，你幾乎可以重寫整個網站。讓我們快速瀏覽一下我早期使用的網站。（再次，你可以在這里獲得Github上的源代碼）。默認情況下，它看起來有點像這樣：

現在讓我們嘗試。讓我們嘗試在這里注入以下CSS負載:

<style>.container, .navbar{display:none;} body { padding: 5px } body:before { content:"We have moved. Head over to www.bogussite.com to continue"; }</style>

所以這個URL看起來像這樣：

http://localhost:57423/?query=<style>.container,.navbar{display:none;}body {padding:5px}body:before{content:"We have moved. Head over to www.bogussite.com to continue";}</style>

看這個URL:

IFrames

注入iframe也是一種XSS漏洞，它可以在相當長的一段時間內不被發現，因為它對終端用戶基本上是不可見的。ifram可以是“無害的”，當人們試圖在他們自己的網站上建立視圖時，視圖里面包含了付費的廣告，這是一種有害的東西，就像把一個虛假的登錄表單寫進頁面一樣。

用戶輸出HTML編碼

現在，如果你一直在看我的示例代碼，你可能會注意到一些事情。我正在談論這個Html.Raw(Context.Request.Query["query"])?。我想承認，我作弊了。默認情況下，當ASP.net Core Razor 將值輸出到頁面上時，它總是對它們進行編碼。如果我們刪除這個原始標簽助手，并嘗試注入一個腳本標簽，我們可以在頁面上看到：

那么，為什么沒有真正運行腳本標簽？它看起來應該是對的？讓我們來看看頁面的源代碼。

看看我們的腳本標簽是如何被寫入HTML的。它已經被我們轉義了，這意味著腳本標記還沒有被實際運行！很棒！因此，對于直接寫入頁面的內容，實際上我們有受到框架的保護。

我們正在展示這些數據的其他地方呢？也許我們正在構建一個SPA，而不是使用ASP.net Core Razor。每個JavaScript庫（甚至jQuery）都會為您編碼數據。但是檢查這是一個自動還是手動的過程是值得的，并且將用戶輸入直接輸出到HTML中的任何地方都應該進行三重檢查以獲得有效的編碼。

值得注意的一個有趣的觀點是，我遇到了一些開發人員，他們堅持HTML編碼，因為他們存儲在數據庫中，然后在網頁上顯示它們（通常，你不使用Razor，所以你沒有得到自動編碼）。這將起作用，但我認為這是一個不好的做法。當您僅在存儲數據時對數據進行編碼時，您就會對反射性XSS攻擊保持開放，因為這些數據從未存儲在任何地方(直接顯示給用戶)。

用戶輸入址編碼

在將用戶數據直接輸出到HTML中時，HTML編碼很好。但有時您可能需要接受用戶輸入并將其放入URL中。URL不會使用與HTML相同的字符進行編碼，因此您可能會發現自己試圖用Raw標簽助手來覆蓋所有內容。?不要這樣做！?因為.NET core 已經覆蓋了URL編碼。

要訪問它，首先需要在Visual Studio的軟件包管理器控制臺中安裝以下nuget軟件包：

Install-Package Microsoft.AspNet.WebUtilities -Pre

然后，您可以像這樣在視圖中編碼您的URL：

<a href="/linktosomething?query=@System.Net.WebUtility.UrlEncode(Context.Request.Query["query"])">Search Query</a>

瀏覽器保護

需要注意的一點是，瀏覽器正在跳入，以保護用戶免受XSS攻擊。 在Chrome中，使用<script> alert （“this is a XSS” ）</ script>這個非常簡單的負載 ，我最終得到了以下結果：

說到這個，你基本在這里可以找到一個試圖繞過Chrome的XSS過濾器的用戶寫的好文章用戶試圖繞過Chrome的XSS過濾器可以在這里找到一個很好的寫作https://blog.securitee.org/?p=37。從本質上講，這將是一場軍備競賽，依靠瀏覽器來保護你的用戶將是非常困難的。更不用說那些不更新瀏覽器的用戶了。

X-XSS-Protection頭

這是另一種保護你的用戶的方法，“很好，但是請編碼你的輸出。”。使用X-XSS-Protection頭文件，您可以指導瀏覽器如何最好地處理它檢測到的任何XSS漏洞。標題有4個不同的值，您可以使用。

X-XSS-Protection: 0

試圖在瀏覽器中禁用XSS保護（如果你想嘗試和測試的話，這是很好的選擇）。

X-XSS-Protection: 1

啟用XSS保護，但如果檢測到XSS，則會嘗試清理輸出（例如對其進行編碼或去除字符）。這樣做可能很危險，因為生成的HTML可能同樣危險。看到這里：http://blog.innerht.ml/the-misunderstood-x-xss-protection/。

X-XSS-Protection: 1; mode=block

啟用XSS保護，并在檢測到任何XSS漏洞的情況下阻止加載頁面。

X-XSS-Protection: 1; report=<reporting-uri>

這是一個chromium內核的頭文件，它允許您向您報告任何在XSS攻擊中被檢測到的URL。

實際上，你應該使用的唯一選項是阻止，因為這將保護你的最佳狀態。您可以在代碼或服務器級別設置標題。對于代碼級別，它和在管道中添加額外的中間件一樣簡單。類似這樣:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory){app.Use(async (context, next) =>{context.Response.Headers.Add("X-Xss-Protection", "1"); ? ? ? ?await next();});app.UseMvc(); }

如果您有興趣進一步閱讀，我們有一篇專門討論X-XSS-Protection header的文章，另外還有一篇關于
每個站點都應該有的3個安全標題.。

總結

跨站腳本攻擊是那些拒絕死亡的攻擊之一，主要是因為人們沒有做基本的事情。正如我們所看到的，在ASP.net Core中，我們的razor 標簽助手是一個保護我們非常好的的解決方案，事實上，框架解決我們的大部分問題，事實上都是HTML編碼。瀏覽器在保護人們方面也正在取得重大進展，但這并不意味著開發者能對自己在保護終端用戶方面的角色感到自滿。

相關文章：

• ASP.NET Core中的OWASP Top 10 十大風險-SQL注入

• ASP.NET Core中的OWASP Top 10 十大風險-失效的訪問控制與Session管理
  

原文地址:http://www.cnblogs.com/chen-jie/p/owasp-top-10-asp-net-core-cross-site-scripting-xss.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的ASP.NET Core中的OWASP Top 10 十大风险-跨站点脚本攻击 (XSS)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。