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

向一个 Web 浏览器发送未经验证的数据会导致该浏览器执行恶意代码。

Cross-Site Scripting (XSS) 漏洞在以下情况下发生：

1.数据通过一个不可信数据源进入云托管 Web 应用程序。对于 Inter-Component Communication Cloud XSS，不可信数据源是通过云主机提供的通信通道从云应用程序的其他组件接收到的数据。


2.未经验证但包含在动态内容中的数据将传送给 Web 用户。

传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。

示例 1：下面的 ASP.NET Web 表单查询雇员的 Azure 表服务并打印其名称。

<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 的值来自用户提供的数据，云提供的存储服务就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Inter-Component Communication Cloud XSS，它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。

示例 3：下面的 ASP.NET Web 表单会从 HTTP 请求中读取一个雇员 ID，并将其显示给用户。

<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 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。

起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码在自己电脑上运行的 URL 呢？ 真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或社交工程的欺骗手段诱使受害者单击链接。当受害者单击该链接时，就会不知不觉地通过易受攻击的 Web 应用程序，使自己的电脑蒙受恶意内容带来的风险。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。

正如例子中所显示的，XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种：

- 如Example 1 和Example 2 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。如果攻击者将危险内容注入到一个数据存储中，随后用户读取此内容并将其包含在动态内容中，则会发生 Inter-Component Communication Cloud XSS 漏洞利用。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。

- 如Example 3 和Example 4 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。

— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中，随后这些危险数据被当作可信赖的数据回写到应用程序中，并储存在动态内容中。

许多现代 Web 框架都会提供对用户输入执行验证的机制（包括 ASP.NET 请求验证和 WCF）。为了突出显示未经验证的输入源，Fortify 安全编码规则包会对 Fortify Static Code Analyzer（Fortify 静态代码分析器）报告的问题动态重新调整优先级，即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。对于 ASP.NET 请求验证，我们还会提供有关何时明确禁用此验证的证据。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程，Fortify 软件安全研究团队开发了 Data Validation（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。