XML Entity Expansion Injection（也称为 XML Bombs）为 DoS 攻击，受益于有效且结构良好的 XML 块，这些块以指数方式扩展，直到耗尽服务器分配的资源。XML 允许定义充当字符串替换宏的自定义实体。通过嵌套重复出现的实体解析，攻击者可能很容易使服务器资源崩溃。

以下 XML 文档显示了 XML Bomb 的一个示例。

    <?xml version="1.0"?>
    <!DOCTYPE lolz [
      <!ENTITY lol "lol">
      <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
      <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
      <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
      <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
      <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
      <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
      <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
      <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
    ]>
    <lolz>&lol9;</lolz>
    

此测试通过将小型 XML 文档的内存扩展到 3 GB 以上来使服务器崩溃。

XML Entity Expansion injection attacks are DoS attacks that benefit from valid and well-formed XML blocks that expand exponentially until they exhaust the server allocated resources. XML allows to define custom entities which act as string substitution macros. By nesting recurrent entity resolutions, an attacker may easily crash the server resources.

下面的 XML 文档介绍了 XML Bomb 的示例。

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

此测试可以在内存中将小型 XML 文档扩展到超过 3GB 而使服务器崩溃。

XML Entity Expansion Injection（也称为 XML Bombs）为 DoS 攻击，受益于有效且结构良好的 XML 块，这些块以指数方式扩展，直到耗尽服务器分配的资源。XML 允许定义充当字符串替换宏的自定义实体。通过嵌套重复出现的实体解析，攻击者可能很容易使服务器资源崩溃。

以下 XML 文档显示了 XML Bomb 的一个示例。

    <?xml version="1.0"?>
    <!DOCTYPE lolz [
      <!ENTITY lol "lol">
      <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
      <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
      <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
      <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
      <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
      <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
      <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
      <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
    ]>
    <lolz>&lol9;</lolz>
    

此测试通过将小型 XML 文档的内存扩展到 3GB 以上来使服务器崩溃。

XML Entity Expansion injection 也称为 XML Bombs，属于 DoS 攻击，利用格式工整的有效 XML 块，它们在耗尽服务器分配的资源之前不断呈指数式扩张。XML 允许定义作为字符串替代宏的自定义实体。通过嵌套复发性实体解析，攻击者可以轻松使服务器资源崩溃。

下面的 XML 文档介绍了 XML Bomb 的示例。

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

此测试可以在内存中将小型 XML 文档扩展到超过 3GB 而使服务器崩溃。

XML Entity Expansion injection 也称为 XML Bombs，属于 DoS 攻击，利用格式工整的有效 XML 块，它们在耗尽服务器分配的资源之前不断呈指数式扩张。XML 允许定义作为字符串替代宏的自定义实体。通过嵌套复发性实体解析，攻击者可以轻松使服务器资源崩溃。

下面的 XML 文档介绍了 XML Bomb 的示例。

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

此测试可以在内存中将小型 XML 文档扩展到超过 3GB 而使服务器崩溃。

XML External Entity 攻击可利用能够在处理时动态构建文档的 XML 功能。XML 实体允许动态包含来自给定资源的数据。外部实体允许 XML 文档包含来自外部 URI 的数据。除非另行配置，否则外部实体会迫使 XML 解析器访问由 URI 指定的资源，例如位于本地计算机或远程系统上的某个文件。这一行为会将应用程序暴露给 XML External Entity (XXE) 攻击，导致对本地系统执行 Denial of Service，获取对本地计算机上文件未经授权的访问权限，扫描远程计算机，并拒绝远程系统的服务。

以下 ABAP 代码演示了不安全的 XML 解析：

...
DATA(ixml) = cl_ixml=>create( ).
DATA(stream_factory) = ixml->create_stream_factory( ).
istream = stream_factory->create_istream_string(
  `<?xml version="1.0" encoding="UTF-8"?> ` &&
  `<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> ` &&
  `<stockCheck>&xxe;</stockCheck>` ).
istream->set_dtd_restriction( level = 0 ).
DATA(document) = ixml->create_document( ).
parser = ixml->create_parser(
                          stream_factory = stream_factory
                          istream        = istream
                          document       = document ).
parser->set_validating( mode = `0` ).
DATA(rc) = parser->parse( ).
...

如果 XML 解析器尝试使用 Linux 系统上的 '/etc/passwd' 密码文件内容来替代实体，则此示例会暴露该文件中的内容。

XML External Entities attacks benefit from an XML feature to build documents dynamically at the time of processing. An XML entity allows to include data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML External Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.

下面的 XML 文档介绍了 XXE 攻击的示例。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///c:/winnt/win.ini" >]><foo>&xxe;</foo>

如果 XML 解析器尝试使用 C:\winnt\win.ini 系统文件中的内容来替代实体，则此示例会暴露该文件中的内容。

在以下情况下会发生 XML External Entity (XXE) 注入：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档的 DTD（文档类型定义）<ENTITY> 的元素中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能会插入嵌套的实体引用，导致 XML 解析器不断消耗越来越多的 CPU 资源。在发生 XML 外部实体注入这种危害更大的攻击的情况下，攻击者可以添加 XML 元素，从而暴露本地文件系统资源的内容或显示是否存在内部网络资源。

例 1：下面是一些易受 XXE 攻击的 Objective-C 代码：

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

假设攻击者能够控制 rawXml，该 XML 的形式如下所示：

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

当服务器对该 XML 进行评估时，<foo> 元素将包含 boot.ini 文件的内容。

XML External Entity 攻击利用 XML 功能在运行时动态生成文档。XML 实体可动态包含来自给定资源的数据。外部实体允许 XML 文档包含来自外部 URI 的数据。除非另行配置，否则外部实体会迫使 XML 解析器访问由 URI 指定的资源，例如位于本地计算机或远程系统上的某个文件。这一行为会将应用程序暴露给 XML External Entity (XXE) 攻击，攻击者可用来对本地系统执行 Denial of Service，获取对本地计算机上文件未经授权的访问权限，扫描远程计算机，并对远程系统执行 Denial of Service。


示例 1：以下 XML 文档显示了 XXE 攻击的示例。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

如果 XML 解析器尝试用 /dev/random 文件的内容替换实体，则此示例可能会导致服务器崩溃（在 UNIX 系统上）。

在以下情况下会发生 XML External Entity (XXE) 注入：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档的 DTD（文档类型定义）的 <ENTITY> 元素中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能会插入嵌套的实体引用，导致 XML 解析器不断消耗越来越多的 CPU 资源。在发生 XML 外部实体注入这种危害更大的攻击的情况下，攻击者可以添加 XML 元素，从而暴露本地文件系统资源的内容或显示是否存在内部网络资源。

例 1：下面是一些易受 XXE 攻击的代码：

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

假设攻击者能够控制 rawXml，该 XML 的形式如下所示：

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

当服务器对该 XML 进行评估时，<foo> 元素将包含 boot.ini 文件的内容。

在以下情况下会发生 XML External Entity (XXE) 注入：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能能够插入嵌套的实体引用，导致 XML 解析器不断消耗越来越多的 CPU 资源。在 XML External Entity Injection 危害更大的情况下，攻击者可能能够添加 XML 元素以公开本地文件系统资源的内容、泄漏内部网络资源的存在状态或公开后端内容本身。

示例 1：下面是一些易受 XXE 攻击的代码：

假定攻击者能控制以下代码的输入 XML：

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

现在假设攻击者将以下 XML 传递到Example 2 中的代码：

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

在处理此 XML 时，将使用系统 boot.ini 文件的内容填充 <foo> 元素的内容。攻击者可能会利用返回到客户端的 XML 元素来窃取数据或获取有关网络资源是否存在的信息。

XML External Entities 攻击利用 XML 功能在运行时动态生成文档。XML 实体可动态包含来自给定资源的数据。外部实体允许 XML 文档包含来自外部 URI 的数据。除非另行配置，否则外部实体会迫使 XML 解析器访问由 URI 指定的资源，例如位于本地计算机或远程系统上的某个文件。这一行为会将应用程序暴露给 XML External Entity (XXE) 攻击，攻击者可用来对本地系统执行 Denial of Service，获取对本地计算机上文件未经授权的访问权限，扫描远程计算机，并拒绝远程系统的服务。


例 1： 下面的 XML 文档介绍了 XXE 攻击的示例。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

如果 XML 解析器尝试使用 /dev/random 文件中的内容来替代实体，则此示例会使服务器（使用 UNIX 系统）崩溃。

XML External Entities 攻击可利用能够在处理时动态构建文档的 XML 功能。XML 实体可动态包含来自给定资源的数据。外部实体允许 XML 文档包含来自外部 URI 的数据。除非另行配置，否则外部实体会迫使 XML 解析器访问由 URI 指定的资源，例如位于本地计算机或远程系统上的某个文件。这一行为会将应用程序暴露给 XML External Entity (XXE) 攻击，从而用于拒绝本地系统的服务，获取对本地计算机上文件未经授权的访问权限，扫描远程计算机，并拒绝远程系统的服务。

下面的 XML 文档介绍了 XXE 攻击的示例。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

示例 XML 文档将读取 /etc/passwd 的内容并将它们包含在文档中。

示例 1：以下代码使用了不安全的 XML 解析器处理来自 HTTP 请求的不可信赖的输入。

def readFile() = Action { request =>
    val xml = request.cookies.get("doc")
    val doc = XMLLoader.loadString(xml)
    ...
}

在以下情况下会发生 XML External Entity (XXE) 注入：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档的 DTD（文档类型定义）<ENTITY> 的元素中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能会插入嵌套的实体引用，导致 XML 解析器不断消耗越来越多的 CPU 资源。在发生 XML 外部实体注入这种危害更大的攻击的情况下，攻击者可以添加 XML 元素，从而暴露本地文件系统资源的内容或显示是否存在内部网络资源。

例 1：下面是一些易受 XXE 攻击的代码：

func parseXML(xml: String) {
    parser = NSXMLParser(data: rawXml.dataUsingEncoding(NSUTF8StringEncoding)!)
    parser.delegate = self
    parser.shouldResolveExternalEntities = true
    parser.parse()
}

假设攻击者能够控制 rawXml 内容，该 XML 的形式如下所示：

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

当服务器对该 XML 进行评估时，<foo> 元素将包含 boot.ini 文件的内容。

XML injection 会在以下情况中出现：

1.数据从一个不可信数据源进入程序。

2.数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能会插入无关的标签，并导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。有时，XML Injection 可以导致 Cross-Site Scripting 或 Dynamic Code Evaluation。

示例 1：

假设攻击者能够控制下列 XML 中的 shoes：

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 ABAP iXML 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可能用于发送敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 甚至可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
   <price>100.00</price>
   <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。


2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1.数据从一个不可信数据源进入程序。

2.数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。在危害最轻的情况下，攻击者可能会插入无关的标签，并导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。有时 XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

示例 1：

假设攻击者能够控制下列 XML 中的 shoes：

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。


2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

这样，攻击者可能只花 1 美元就可以购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。


2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

示例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 XML 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。


如果攻击者控制了已解析 XML 文档的前部或全部内容，则可能会发生这种攻击的一种更严重的形式，称为 XML External Entity (XXE) Injection。

示例 2：下面是一些易受 XXE 攻击的代码：

假定攻击者能控制以下代码的输入 XML：

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

现在假设攻击者将以下 XML 传递到Example 2 中的代码：

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

在处理此 XML 时，将使用系统 boot.ini 文件的内容填充 <foo> 元素的内容。攻击者可能会利用返回到客户端的 XML 元素来窃取数据或获取有关网络资源是否存在的信息。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
    <price>100.00</price>
    <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2.数据写入到 XML 文档或解析为 XML。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
    <price>100.00</price>
    <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1.数据从一个不可信赖的数据源进入程序。

2.数据写入到 XML 文档或解析为 XML。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

示例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XML injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。


2. 数据写入到 XML 文档中。

应用程序通常使用 XML 来存储数据或发送消息。当 XML 用于存储数据时，XML 文档通常会像数据库一样进行处理，而且可能会包含敏感信息。XML 消息通常在 web 服务中使用，也可用于传输敏感信息。XML 消息甚至还可用于发送身份验证凭据。

如果攻击者能够写入原始 XML，则可以更改 XML 文档和消息的语义。危害最轻的情况下，攻击者可能会插入无关的标签，导致 XML 解析器抛出异常。XML injection 更为严重的情况下，攻击者可以添加 XML 元素，更改身份验证凭据或修改 XML 电子商务数据库中的价格。还有一些情况，XML injection 可以导致 cross-site scripting 或 dynamic code evaluation。

例 1：

假设攻击者能够控制下列 XML 中的 shoes。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

现在假设，在后端 Web 服务请求中包含该 XML，用于订购一双鞋。假设攻击者可以修改请求，并将 shoes 替换成 shoes</item><price>1.00</price><item>shoes。新的 XML 如下所示：

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

当使用 SAX 解析器时，第二个 <price> 标签中的值将会覆盖第一个 <price> 标签中的值。这样，攻击者就可以只花 1 美元购买一双价值 100 美元的鞋。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态构造一个 XPath 查询。

示例 1：下列代码可动态地构造并执行一个 XPath 查询，为指定的帐户 ID 检索电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

...
string acctID = Request["acctID"];
string query = null;
if(acctID != null) {
       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");
       sb.append(acctID);
       sb.append("']/email/text()");
       query = sb.toString();
}

XPathDocument docNav = new XPathDocument(myXml);
XPathNavigator nav = docNav.CreateNavigator();
nav.Evaluate(query);
...

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。




2. 数据用于动态构造一个 XPath 查询。

示例 1：以下 Objective-C 代码会调用 C API，它会动态地构造并执行一个 XPath 查询，用于检索指定帐户 ID 的电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态构造一个 XPath 查询。

示例 1：下列代码可动态地构造并执行一个 XPath 查询，为指定的帐户 ID 检索电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

query = "/accounts/account[acctID='" & url.acctID & "']/email/text()";
selectedElements = XmlSearch(myxmldoc, query);

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。




2. 数据用于动态构造一个 XPath 查询。

示例 1：下列代码可动态地构造并执行一个 XPath 查询，为指定的帐户 ID 检索电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态构造一个 XPath 查询。

示例 1：下列代码可动态地构造并执行一个 XPath 查询，为指定的帐户 ID 检索电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

...
<?php
load('articles.xml');
 
$xpath = new DOMXPath($doc);
$emailAddrs = $xpath->query(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;);
//$arts = $xpath->evaluate(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;)
 
foreach ($emailAddrs as $email)
{
    echo $email->nodeValue."";
}
	?>
...

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XPath injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态构造一个 XPath 查询。

示例 1：下列代码可动态地构造并执行一个 XPath 查询，为指定的帐户 ID 检索电子邮件地址。由于该帐户 ID 是从 HTTP 请求中读取的，因此不受信任。

...
tree = etree.parse('articles.xml')
emailAddrs = "/accounts/account[acctID=" + request.GET["test1"] + "]/email/text()"
r = tree.xpath(emailAddrs)
...

在正常情况下（例如搜索属于帐号 1 的电子邮件地址），此代码执行的查询将如下所示：

/accounts/account[acctID='1']/email/text()

但是，由于这个查询是动态构造的，由一个不变的查询字符串和一个用户输入字符串连接而成，因此只有在 acctID 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 acctID 输入字符串 1' or '1' = '1，则该查询会变成：

/accounts/account[acctID='1' or '1' = '1']/email/text()

附加条件 1' or '1' = '1 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

//email/text()

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在文档中的所有电子邮件地址，而不论其指定所有者是谁。

XQuery injection 会在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态构造一个 XQuery 表达式。

示例 1：下列代码可动态构造和执行 XQuery 表达式，以根据给定用户名和密码的组合检索用户帐户。由于用户名和密码是从 HTTP 请求中读取的，因此不可信。

  ...

  String squery = "for \$user in doc(users.xml)//user[username='" + Request["username"] + "'and pass='" + Request["password"] + "'] return \$user";

  Processor processor = new Processor();

  XdmNode indoc = processor.NewDocumentBuilder().Build(new Uri(Server.MapPath("users.xml")));

  StreamReader query = new StreamReader(squery);
  XQueryCompiler compiler = processor.NewXQueryCompiler();
  XQueryExecutable exp = compiler.Compile(query.ReadToEnd());
  XQueryEvaluator eval = exp.Load();
  eval.ContextItem = indoc;

  Serializer qout = new Serializer();
  qout.SetOutputProperty(Serializer.METHOD, "xml");
  qout.SetOutputProperty(Serializer.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Strict//EN");
  qout.SetOutputProperty(Serializer.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
  qout.SetOutputProperty(Serializer.INDENT, "yes");
  qout.SetOutputProperty(Serializer.OMIT_XML_DECLARATION, "no");

  qout.SetOutputWriter(Response.Output);
  eval.Run(qout);

  ...
  

在正常情况下，诸如搜索采用相应用户名和密码的用户帐户，该代码执行的表达式如下：

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

但是，由于这个表达式是动态构造的，由一个常数基查询字符串和一个用户输入字符串连接而成，因此只有在 username 或 password 不包含单引号字符时，才会正确执行这一查询。如果攻击者为 username 输入字符串 admin' or 1=1 or ''='，则该查询会变成：

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user

添加条件 admin' or 1=1 or ''=' 会使 XQuery 表达式永远评估为 true。因此，该查询在逻辑上等同于更简单的查询：

//user[username='admin']

如此简化的查询会使攻击者绕过查询与密码匹配的要求；现在查询会返回文档中存储的管理用户，无论输入什么样的密码。