Cross-Site Scripting: Inter-Component Communication (Cloud)

傳送未經驗證的資料至網路瀏覽器，會導致瀏覽器執行惡意的程式碼。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入存放在雲端的 Web 應用程式。如果是 Inter-Component Communication Cloud XSS，不可信賴的來源是指透過雲端主機提供的通訊通道，從雲端應用程式的其他元件接收的資料。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下 ASP.NET 網頁表單會在 Azure Table Service 中查詢員工並列印名稱。

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>

其中，EmployeeName 是定義如下的表單控制項：

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

範例 2：以下 ASP.NET 程式碼片段的功能與之前的 Example 1 相當，不過卻是以程式設計方式來實作所有的表單元素。

protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;

Name 值正常運作時，這些程式碼範例也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 Name 值是從雲端提供的儲存服務中讀取的，且顯然是由分散式應用程式管理這些值的內容。但是，如果 Name 的值是從使用者提供的資料中產生，那麼雲端提供的儲存服務可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊，被稱作 Inter-Component Communication Cloud XSS，是特別狡詐的，因為間接的資料儲存方式使得該威脅難以辨別，而且提高了該攻擊會影響到多個使用者的可能性。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

範例 3：以下 ASP.NET 網頁表單會從 HTTP 要求讀取員工識別碼，然後顯示給使用者。

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

其中，Login 和 EmployeeID 是定義如下的表單控制項：

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

範例 4：以下的 ASP.NET 程式碼片段會示範以程式設計方式來實作 Example 3。

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

如 Example 1 和 Example 2 所述，如果 Login 只包含標準英數字元，這些範例就會正確運作。如果 Login 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？ 真正的危險是攻擊者會建立惡意的 URL，然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 和 Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Inter-Component Communication Cloud XSS 攻擊會在以下情況出現：攻擊者把危險內容注入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 3 和 Example 4 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 ASP.NET 要求驗證和 WCF)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。如果是 ASP.NET 要求驗證，我們也會針對何時明確停用驗證提供證據。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。