随着简单 XML API、Web 服务和 Rich Internet Applications (RIAs) 的发展，更多组织几乎在所有方面(从配置文件到远程过程调用)都采用 XML 作为数据格式。一般的Web2.0网站和复杂的WEB应用使用XML作为数据格式。XML应用程序更容易受到代码注入的攻击，尤其是 XPath 注入攻击。

Path语言表达的句法与SQL查询在许多方面都有些相似，但是Xpath注入攻击的危险性更胜于SQL注入攻击。

南昌网站建设公司百恒网工程师总结:xPath注入与SQL注入攻击带来的危害相似，攻击者能利用Xpath注入同样能迅速获取数据库的删除、修改、读取权限，并可以利用数据库的特性迅速获取服务器的控制权限;同时大多数B/S架构的数据库都提供了某种形式的访问和权限控制，限制用户访问某些表格、字段或者查询。这种权限控制限制攻击者访问应用程序的数据库账户，而XPath没有为数据库文件提供访问限制，攻击者利用Xpath注入能够查询这个数据库中的全部XML对象。

XPath 注入预防

因为 XPath 注入攻击与 SQL 注入攻击非常类似，所以很多预防方法也类似。这些预防方法中，多数也可以类似地应用于预防其他类型的代码注入攻击。

身份验证

不论面对何种应用程序、环境或语言，都应遵守以下的最佳实践：

假定所有输入都可疑。

不仅要验证数据的类型，还要验证其格式、长度、范围和内容(例如，一个简单的正则表达式 if (/^"*^';>()/) 就可以找出大多数可疑的特殊字符)。

在客户机和服务器上都要验证数据，因为客户机验证非常容易绕过。

根据安全软件开发的最佳实践，遵守一致的编写和 [missing word] 策略实现应用程序安全性。

在发布应用程序之前测试已知的威胁。参考资料 中的 “Fuzz Testing” 介绍了测试方法。

参数化

网站建设公司百恒网络认为与多数数据库应用程序不同，XPath 不支持参数化查询的概念，但是您可以使用其他 API(比如 XQuery)模拟该概念。您不需要构建字符串表达式，然后传给 XPath 解析器以便在运行时动态执行，而是通过创建保存查询的外部文件使查询参数化。

Web 服务器上的数据检查

要防止 XPath 注入和其他形式的代码注入，应该检查所有从 Web 服务器传到后端服务的数据。例如，对于 Apache 您可以使用 Mod_Security 筛选器(比如 SecFilterSelective THE_REQUEST "('|")")查找字符串中的单引号和双引号并禁止它们。您也可以使用同样的方法筛选和禁止其他形式的特殊字符，比如 ("*^';>/)，这些字符都可以用于各种注入攻击。这种方法对于使用基于 REST 或 SOAP 的 XML 服务的应用程序可能很好，但是在其他情况下可能不适用。通常的最佳实践是，从最初的设计到应用程序实现都采用智能安全设计。

希望对广大站长或网站建设公司技术人员有所帮助，如对此不太理解的，可以与南昌网络公司百恒网络技术部联系。