XPATH 注入的介绍与代码防御

   软件未正确对 XML 中使用的特殊元素进行无害化处理，导致攻击者能够在终端系统处理 XML 的语法、内容或命令之前对其进行修改。在 XML 中，特殊元素可能包括保留字或字符，例如“<”、“>”、“"”和“&”，它们可能用于添加新数据或修改 XML 语法。我们发现用户可控制的输入并未由应用程序正确进行无害化处理，就在 XPath 查询中使用。例如，假定 XML 文档包含“user”名称的元素，每个元素各包含 3 个子元素 －“name”、“password”和 “account”。这时下列 XPath 表达式会产生名称为“jsmith”、密码为“Demo1234”的用户的帐号（如果没有这样的用户，便是空字符串）：

  string(//user[name/text()='jsmith' and password/text()='Demo1234']/account/text())

以下是应用程序的示例（采用 Microsoft ASP.NET 和 C#）：

  XmlDocument XmlDoc = new XmlDocument();
  XmlDoc.Load("...");
  ...
  XPathNavigator nav = XmlDoc.CreateNavigator();
  XPathExpression expr = nav.Compile("string(//user[name/text()='"+TextBox1.Text+"' and password/text()='"+TextBox2.Text+"']/account/text())");
  String account=Convert.ToString(nav.Evaluate(expr));	
  if (account=="")
  {
  	// name+password pair is not found in the XML document - login failed.
  }
  else
  {
  	// account found -> Login succeeded. Proceed into the application
  }

使用此类代码时，攻击者可以注入 XPath 表达式（非常类似 SQL 注入），例如，提供以下值作为用户名：

  ' or 1=1 or ''='

此数据会导致原始 XPath 的语义发生更改，使其始终返回 XML 文档中的第一个帐号。

这意味着虽然攻击者未提供任何有效用户名或密码，但仍将登录（作为 XML 文档中列出的第一个用户）。

0x02 主要修复思路

        未对用户输入正确执行危险字符清理，可能导致恶意攻击者可以访问存储在敏感数据资源中的信息。缓解修复：

假设所有输入都是恶意的。使用黑名单和白名单的适当组合以确保系统仅处理有效和预期的输入。

0x03 Asp.Net

      我们可以使用验证控件，将输入验证添加到“Web 表单”页面。验证控件提供适用于所有常见类型的标准验证的易用机制 － 例如，测试验证日期是否有效，或验证值是否在范围内 － 以及进行定制编写验证的方法。此外，验证控件还使我们能够完整定制向用户显示错误信息的方式。验证控件可搭配“Web 表单”页面的类文件中处理的任何控件使用，其中包括 HTML 和 Web 服务器控件。

为了确保用户输入仅包含有效值，我们可以使用以下其中一种验证控件：

a. “RangeValidator”：检查用户条目（值）是否在指定的上下界限之间。 您可以检查配对数字、字母字符和日期内的范围。

b. “RegularExpressionValidator”：检查条目是否与正则表达式定义的模式相匹配。 此类型的验证使您能够检查可预见的字符序列，如社会保险号码、电子邮件地址、电话号码、邮政编码等中的字符序列。

         重要注意事项：验证控件不会阻止用户输入或更改页面处理流程，它们只会设置错误状态，并产生错误消息。程序员的职责是，在执行进一步的应用程序特定操作前，测试代码中控件的状态。有两种方法可检查用户输入的有效性：

1. 测试常规错误状态

在您的代码中，测试页面的 IsValid 属性。该属性会将页面上所有验证控件的 IsValid 属性值汇总（使用逻辑 AND）。如果将其中一个验证控件设置为无效，那么页面属性将会返回 false。

2. 测试个别控件的错误状态

在页面的“验证器”集合中循环，该集合包含对所有验证控件的引用。然后，您就可以检查每个验证控件的 IsValid 属性。

0x03 J2EE

1 输入数据验证

     虽然为了用户的方便，可以提供“客户端”层的数据验证，但必须在“服务器”层（也就是 Servlet）执行数据验证。客户端验证本身就不安全，因为这些验证可轻易绕过，例如，通过禁用 JavaScript。一份好的设计通常需要 Web 应用程序框架，以提供服务器端实用程序例程，从而验证以下内容：[1] 必需字段[2] 字段数据类型（缺省情况下，所有 HTTP 请求参数都是“字符串”）[3] 字段长度[4] 字段范围[5] 字段选项[6] 字段模式[7] cookie 值[8] HTTP 响应好的做法是将以上例程作为“验证器”实用程序类中的静态方法实现。以下部分描述验证器类的一个示例。