若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

示例：应用程序采用反射技术的一个共同理由是实现自己的命令发送器。以下例子显示了一个没有使用反射的命令发送器：

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    if (ctl == "Add) {
      ao = new AddCommand();
    } else if (ctl == "Modify") {
      ao = new ModifyCommand();
    } else {
      throw new UnknownActionError();
    }
    ao.doAction(params);

程序员可能会修改这段代码，以便按照如下情况使用反射：

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.doAction(params);

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，这种修改允许攻击者将任意实现了 Worker 接口的对象实例化。如果命令发送器仍对 access control 负责，那么只要程序员创建实现 Worker 接口的新类，就务必要修改发送器的 access control 代码。如果未修改 access control 代码，那么一些 Worker 类就没有任何 access control 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.checkAccessControl(params);
    ao.doAction(params);

虽然有所改进，但它鼓励了采用分散化的手段进行 access control，这使程序员在 access control 上更加容易犯错误。

如果攻击者可以提供应用程序随后用于确定要实例化的类或要调用的方法的值，则攻击者可能会通过应用程序创建意外的控制流路径。这可能使攻击者可以绕过身份验证或访问控制检查，或者可能会导致应用程序不按预期方式运行。

示例：以下操作方法将向外部 Web 服务发起异步请求，并设置 continuationMethod 属性，该属性用于确定接收响应时要调用的方法的名称。

public Object startRequest() {
    Continuation con = new Continuation(40);

    Map<String,String> params = ApexPages.currentPage().getParameters();

    if (params.containsKey('contMethod')) {
        con.continuationMethod = params.get('contMethod');
    } else {
        con.continuationMethod = 'processResponse';
    }

    HttpRequest req = new HttpRequest();
    req.setMethod('GET');
    req.setEndpoint(LONG_RUNNING_SERVICE_URL);
    this.requestLabel = con.addHttpRequest(req);
    return con;
}

此实现允许通过运行时请求参数设置 continuationMethod 属性，这使得攻击者能够调用与名称匹配的任何函数。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

示例：程序员通常使用反射来实现命令发送器。以下示例显示了一个未使用反射的命令发送器：

...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (String.Compare(ctl,"Add") = 0) Then
        ao.DoAddCommand(Request)
Else If (String.Compare(ctl,"Modify") = 0) Then
        ao.DoModifyCommand(Request)
Else
        App.EventLog("No Action Found", 4)
End If
...

程序员可能会修改这段代码，以便按照如下情况使用反射：

...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
CallByName(ao, ctl, vbMethod, Request)
...

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，进行这样的修改后，攻击者就可以调用任意一个实施了 Worker 对象的方法。如果命令发送器对 access control 负责，那么，只要程序员在 Worker 类中创建了新方法，就必须修改发送器的 access control 逻辑。如果 access control 逻辑过期，那么某些 Worker 方法将不具有任何 access control。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (ao.checkAccessControl(ctl,Request) = True) Then
        CallByName(ao, "Do" & ctl & "Command", vbMethod, Request)
End If
...

虽然有所改进，但它鼓励了采用分散化的手段进行 access control，这使程序员在 access control 上更加容易犯错误。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。

如果攻击者能够将文件上传到应用程序的路径或者库路径上出现的位置，那么对应用程序来说，情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。
示例：应用程序使用反射 API 的一个共同理由是实现自己的命令发送器。下面的例子显示了一个 JNI 命令发送器，它使用反射来执行 Java 方法，该方法由读取自 CGI 请求中的数值进行验证。执行该代码允许攻击者调用在 clazz 中定义的所有函数。

char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

如果攻击者能够将文件上传到应用程序的类路径或者添加应用程序类路径的新入口，那么对应用程序来说，情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。
示例：应用程序使用反射 API 的一个共同理由是实现自己的命令发送器。以下例子显示了一个没有使用反射的命令发送器：

String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
  ao = new AddCommand();
} else if (ctl.equals("Modify")) {
  ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
ao.doAction(request);

程序员可能会修改这段代码，以便按照如下情况使用反射：

    String ctl = request.getParameter("ctl");
    Class cmdClass = Class.forName(ctl + "Command");
    Worker ao = (Worker) cmdClass.newInstance();
    ao.doAction(request);

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，这种修改允许攻击者将任意实现了 Worker 接口的对象实例化。如果命令发送器仍对 access control 负责，那么只要程序员创建实现 Worker 接口的新类，就务必要修改发送器的 access control 代码。如果未修改 access control 代码，那么一些 Worker 类就没有任何 access control 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);

虽然有所改进，但它鼓励了采用分散化的手段进行 access control，这使程序员在 access control 上更加容易犯错误。

这段代码还突出反映了通过反射构建命令发送器所引发的安全问题。攻击者能为任意种类的对象调用默认构造函数。实际上，攻击者甚至不会局限于使用实现了 Worker 接口的对象；系统中所有对象的默认构造函数都可以调用。如果对象没有实现 Worker 接口，则会在分配到 ao 前抛出 ClassCastException。但如果构造函数执行了一些有利于攻击者的操作，则说明已经造成损害。对于简单的应用程序来说，这种情况的影响并不大，但是对于日趋复杂的大型应用程序来说，攻击者利用构造函数发动攻击并非没有可能。

如果在由反射调用返回的不可信任对象上调用使用即时调用者的类加载器检查执行任务的特定 Java API，则可能会危害访问检查，进而影响代码执行链。这些 Java API 会绕过可确保执行链中的所有调用者具有必需安全权限的 SecurityManager 检查。由于此类 API 可以绕过安全访问检查，使系统容易受到远程攻击，因此应格外小心，确保不要在由反射返回的不可信任对象上调用这些 API。有关这些 Java API 的更多信息，请参见“Secure Coding Guidelines for the Java Programming Language”中的准则 9。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。

示例 1：应用程序使用选择器 API 的一个共同理由是实现自己的命令发送器。下面的例子显示了一个 Objective-C 命令发送器，它使用反射来执行任意方法，该方法由读取自自定义 URL 方案请求中的数值进行验证。攻击者可以利用这种实现方法调用与 UIApplicationDelegate 类中定义的方法签名匹配的任何函数。

...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
  sourceApplication:(NSString *)sourceApplication annotation:(id)annotation  {

    NSString *query = [url query];
    NSString *pathExt = [url pathExtension];
    [self performSelector:NSSelectorFromString(pathExt) withObject:query];
...

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

如果攻击者能够将文件上传到应用程序的类路径或者添加应用程序类路径的新入口，那么对应用程序来说，情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。
示例：应用程序使用反射 API 的一个共同理由是实现自己的命令发送器。以下例子显示了一个没有使用反射的命令发送器：

$ctl = $_GET["ctl"];
$ao = null;
if (ctl->equals("Add")) {
  $ao = new AddCommand();
} else if ($ctl.equals("Modify")) {
  $ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
$ao->doAction(request);

程序员可能会修改这段代码，以便按照如下情况使用反射：

    $ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
    $ao->doAction(request);

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，这种修改允许攻击者将任意实现了 Worker 接口的对象实例化。如果命令发送器仍对 access control 负责，那么只要程序员创建实现 Worker 接口的新类，就务必要修改发送器的 access control 代码。如果未修改 access control 代码，那么一些 Worker 类就没有任何 access control 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

	$ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
	$ao->checkAccessControl(request);
	ao->doAction(request);

虽然有所改进，但它鼓励了采用分散化的手段进行 access control，这使程序员在 access control 上更加容易犯错误。

这段代码还突出反映了通过反射构建命令发送器所引发的安全问题。攻击者能为任意种类的对象调用默认构造函数。实际上，攻击者甚至不会局限于使用实现了 Worker 接口的对象；系统中所有对象的默认构造函数都可以调用。如果对象没有实现 Worker 接口，则会在分配到 $ao 前抛出 ClassCastException。但如果构造函数执行了一些有利于攻击者的操作，则说明已经造成损害。对于简单的应用程序来说，这种情况的影响并不大，但是对于日趋复杂的大型应用程序来说，攻击者利用构造函数发动攻击并非没有可能。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

如果攻击者能够将文件上传到应用程序的类路径或者添加应用程序类路径的新入口，那么对应用程序来说，情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可以使攻击者避开身份验证、避开访问控制检查，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

如果攻击者可以将文件上传到应用程序的加载路径中的一个位置，或者可以向应用程序的加载路径中添加新条目，那么情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。
示例：程序员使用反射通常是为了实现自身的命令发送器。以下例子显示了一个没有使用反射的命令发送器：

ctl = req['ctl']
if ctl=='add'
  addCommand(req)
elsif ctl=='modify'
  modifyCommand(req)
else
  raise UnknownCommandError.new
end

程序员可能会修改这段代码，以便按照如下情况使用反射：

ctl = req['ctl']
ctl << "Command"
send(ctl)

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，重构允许攻击者运行任何以 "Command" 一词结尾的方法。如果命令发送器仍对访问控制负责，那么，只要程序员创建以 "Command" 结尾的新方法，他们一定要记得修改发送器的访问控制代码。即使是这样，当您有多个同样命名的方法时，常见做法可以是使用 define_method() 动态创建方法，或者通过覆盖 missing_method() 来调用方法。审计和跟踪这些方法以及访问控制代码在这些方法中的使用方式是非常困难的，当考虑到这一点还将取决于所加载的其他库代码时，可能会使这个近乎不可完成的任务能够以这种方式正确地完成。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。

示例 1：应用程序使用选择器 API 的一个共同理由是实现自己的命令发送器。下面的例子显示了一个 Swift 命令发送器，它使用反射来执行任意方法，该方法由读取自自定义 URL 方案请求中的数值进行验证。攻击者可以利用这种实现方法调用与 UIApplicationDelegate 类中定义的方法签名匹配的任何函数。

func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let query = url.query
    let pathExt = url.pathExtension
    let selector = NSSelectorFromString(pathExt!)
    performSelector(selector, withObject:query)
    ...
}

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

示例：各种程序使用 CallByName 的一个共同原因是，为了实施各自的命令发送器。以下示例显示了一个没有使用 CallByName 函数的命令发送器：

...
Dim ctl As String
Dim ao As new Worker
ctl = Request.Form("ctl")
If String.Compare(ctl,"Add") = 0 Then
	ao.DoAddCommand Request
Else If String.Compare(ctl,"Modify") = 0 Then
	ao.DoModifyCommand Request
Else
	App.EventLog "No Action Found", 4
End If
...

程序员可能会修改这段代码，以便按照如下情况使用反射：

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
CallByName ao, ctl, vbMethod, Request
...

乍一看，这种修改似乎具有许多优点。代码的行数比原先少了，if/else 代码段也完全删除了，而且还可以在不改变命令发送器的情况下增加新的命令类型。

然而，进行这样的修改后，攻击者就可以调用任意一个实施了 Worker 对象的方法。如果命令发送器仍对 access control 负责，那么，只要程序员在 Worker 类中创建了新方法，就必须修改发送器的 access control 代码。如果无法修改 access control 代码，那么一些 Worker 方法就不具有任何 access control 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
If ao.checkAccessControl(ctl,Request) = True Then
	CallByName ao, "Do" & ctl & "Command", vbMethod, Request
End If
...

虽然有所改进，但它鼓励了采用分散化的手段进行 access control，这使程序员在 access control 上更加容易犯错误。

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 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:///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 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>

当使用 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>

当使用 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 消息通常在 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 美元的鞋。