通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将堆栈跟踪输出到“Debug”控制台或日志文件：

  try {
    ...
  }
  catch(e:Error) {
    trace(e.getStackTrace());
  }

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息恰好可以告诉攻击者入侵这一系统的可能性究竟有多大。例如，一则数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，搜索路径可能会暗示操作系统的类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码将一个异常消息写入调试日志：

try {
    ...
} catch (Exception e) {
    System.Debug(LoggingLevel.ERROR, e.getMessage());
}

该错误消息可使攻击者能够制定攻击计划。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。
示例 1：下面的代码会构造一个数据库连接字符串，使用它新建一个数据库连接，并将其写入控制台。

string cs="database=northwind;server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);

根据系统配置，此信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

通过日志或打印功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。
示例 1：以下代码会将路径环境变量输出到标准错误流：

  char* path = getenv("PATH");
  ...
  fprintf(stderr, "cannot find exe on path %s\n", path);

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息可以准确地告诉攻击者系统容易遭受哪种类型的攻击。例如，一则数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，搜索路径可能会暗示操作系统的类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施。

通过日志或打印功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。
示例：下列代码要求对所有任务相关的存储区域、终端控制表和指定的数据区域进行事务转储。

...
EXEC CICS DUMP TRANSACTION
  DUMPCODE('name')
  FROM (data-area)
  LENGTH (data-value)
END-EXEC.
...

依据这一系统配置，该信息可转储到控制台，写成日志文件，或者显示给用户。在某些情况下，该错误消息恰好可以告诉攻击者入侵这一系统的可能性究竟有多大。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。

通过打印或日志功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例：以下代码将写入本地文件系统上的文件：

<cfscript>
    try { 
        obj = CreateObject("person"); 
    } 
    catch(any excpt) { 
        f = FileOpen("c:\log.txt", "write"); 
        FileWriteLine(f, "#excpt.Message#");
        FileClose(f);
    }
</cfscript>

将此信息写入日志文件。在某些情况下，该消息准确告诉攻击者这一系统易受何种攻击。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：下面的代码将一个异常写入本地文件：

  final file = await File('example.txt').create();
  final raf = await file.open(mode: FileMode.write);
  final data = String.fromEnvironment("PASSWORD");
  raf.writeString(data);

根据系统配置，此信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

信息泄漏也是移动计算环境中的一个问题。

通过日志或打印功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。
示例 1：以下代码会将路径环境变量输出到标准错误流：

  path := os.Getenv("PATH")
  ...
  log.Printf("Cannot find exe on path %s\n", path)

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型有哪些。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，搜索路径可能会暗示操作系统的类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施。

当系统数据或调试信息通过套接字或网络连接使程序流向远程机器时，就会发生外部信息泄露。外部信息泄露会暴露有关操作系统、完整路径名、现有用户名或配置文件位置的特定数据，从而使攻击者有机可乘，它比内部信息（攻击者更难访问）泄露更严重。

示例 1：以下代码泄露了 HTTP 响应中的异常信息：

protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
    ...
    PrintWriter out = res.getWriter();
    try {
        ...
    } catch (Exception e) {
      out.println(e.getMessage());
    }
}

该信息可能会显示给远程用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

信息泄漏也是移动计算环境中的一个问题。在移动平台上，可以从各种来源下载应用程序，并且可以在同一设备上同时运行这些应用程序。因为恶意软件在银行应用程序附近运行的可能性很高，所以应用程序的作者需要注意消息所包含的信息，这些消息将会发送给在设备上运行的其他应用程序。

示例 2：以下代码可向所有注册的 Android 接收者广播所捕获异常的堆栈跟踪。

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

这是另一种情况，特定于移动环境。大多数移动设备现在执行的是“近场通信”(NFC) 协议，以便使用无线电通信在设备之间快速共享信息。它在设备极为贴近或互相接触时有效。即使 NFC 的通信范围仅局限于几厘米，也可能发生窃听、修改数据以及各种其他类型的攻击情况，因为 NFC 本身并不能确保通信安全。

示例 3：Android 平台为 NFC 提供了支持。以下代码将创建一条消息，该消息会被发送给所在范围内的其他设备。

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

NFC 数据交换格式 (NDEF) 消息包含类型化数据、URI 或自定义应用程序有效负载。如果该消息包含与应用程序有关的信息（如其名称、MIME 类型或设备软件版本），则此信息可能会泄露给窃听者。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准错误流：

var http = require('http');
...

http.request(options, function(res){
  ...
}).on('error', function(e){
  console.log('There was a problem with the request: ' + e);
});
...

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准错误流：

try {
    ...
} catch (e: Exception) {
    e.printStackTrace()
}

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

信息泄漏也是移动计算环境中的一个问题。

示例 2：以下代码记录了在 Android 平台上捕获的异常的堆栈跟踪。

...
try {
  ...
} catch (e: Exception) {
    Log.e(TAG, Log.getStackTraceString(e))
}
...

通过日志或打印功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。
示例 1：以下代码会将系统信息泄漏到系统日志中：

...
NSString* deviceID = [[UIDevice currentDevice] name];

NSLog(@"DeviceID: %@", deviceID);
...

在移动世界中，当设备丢失或被盗时，就会产生有关维护系统信息的其他方面的忧虑。攻击者一旦拥有 iOS 设备之后，即可通过对设备进行 USB 连接来访问其中的大量数据。iOS 属性列表 (plist) 及 SQLite 数据库等文件很容易访问，可能会泄露个人信息。通常的做法是，不要将相关的隐私信息存储在文件系统中不受保护的位置。

示例 2：下列代码向用户默认值列表中添加了一个 deviceID 条目，并立即将其存储在一个 plist 文件中。

...
NSString* deviceID = [[UIDevice currentDevice] name];

[defaults setObject:deviceID forKey:@"deviceID"];
[defaults synchronize];
...

Example 2 中的代码会将移动设备上的系统信息存储在该设备上一个不受保护的 plist 文件中。尽管许多开发人员认为 plist 文件是存储所有数据的安全位置，但这不是绝对的，特别是涉及到系统信息和隐私问题时，因为 plist 文件可被持有该设备的任何人读取。

依据这一系统配置，该信息可转储到控制台，写成日志文件，或者显示给用户。在某些情况下，这个错误消息正好可以准确地告诉攻击者系统被入侵的可能性有多大。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准错误流：

<?php
    ...
    echo "Server error! Printing the backtrace";
    debug_print_backtrace();
    ...
?>

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准输出流：

    try:
        ...
    except:
        print(sys.exc_info()[2])

此信息将转储到控制台。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码会将一个异常写入标准错误流：

...
begin
  log = Logger.new(STDERR)
  ...
rescue Exception
    log.info("Exception: " + $!)
...
end

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。当然，Example 1 还有一个问题就是挽救根 Exception 而不是特定类型或错误/异常，这意味着它将捕获所有异常，从而可能导致其他未考虑到的负面影响。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例 1：以下代码针对标准输出流输出系统信息：

...
println(Properties.osName)
...

根据这一系统配置，该信息可能会转储到控制台、写入日志文件或公开给用户。在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在Example 1 中，泄露的信息可能会暗示有关操作系统类型、系统上安装了哪些应用程序以及管理员在配置程序时采取了哪些保护措施的信息。

通过日志或打印功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。



在移动世界中，当设备丢失或被盗时，就会产生有关维护系统信息的其他方面的忧虑。攻击者一旦拥有 iOS 设备之后，即可通过对设备进行 USB 连接来访问其中的大量数据。iOS 属性列表 (plist) 及 SQLite 数据库等文件很容易访问，可能会泄露个人信息。通常的做法是，不要将相关的隐私信息存储在文件系统中不受保护的位置。

示例：以下代码会将设备标识符打印到系统日志：

let deviceName = UIDevice.currentDevice().name
...
NSLog("Device Identifier: %@", deviceName)

依据这一系统配置，该信息可转储到控制台，写成日志文件，或者显示给用户。在某些情况下，这个错误消息正好可以准确地告诉攻击者系统被入侵的可能性有多大。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他的错误消息可以揭示有关该系统的更多间接线索。

通过打印或日志记录功能将系统数据或调试信息发送到本地文件、控制台或屏幕时，就会发生内部信息泄露。

示例：以下代码向脚本调试器发送 ASPError 对象，如 Microsoft Script Debugger：

...
Debug.Write Server.GetLastError()
...

在某些情况下，该错误消息恰好可以告诉攻击者入侵这一系统的可能性究竟有多大。例如，一个数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息会泄露更多有关系统的间接线索，如操作系统的类型、系统上安装了哪些应用程序，以及管理员在配置应用程序时做了哪些方面的努力。

程序可能无法成功释放某一项系统资源。

资源泄露至少有两种常见的原因：

－ 错误状况及其他异常情况。

－ 未明确程序的哪一部份负责释放资源。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起 Denial of Service 攻击。

示例：下面的方法绝不会关闭它所打开的文件句柄。FileInputStream 中的 finalize() 方法最终会调用 close()，但是不能确定何时会调用 finalize() 方法。在繁忙的环境中，这会导致 JVM 用尽它所有的文件句柄。

private void processFile(String fName) throws FileNotFoundException, IOException {
  FileInputStream fis = new FileInputStream(fName);
  int sz;
  byte[] byteArray = new byte[BLOCK_SIZE];
  while ((sz = fis.read(byteArray)) != -1) {
    processBytes(byteArray, sz);
  }
}

程序可能无法成功释放某一项系统资源。


资源泄露至少有两种常见的原因：

－ 错误状况及其他异常情况。

－ 未明确程序的哪一部份负责释放资源。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起 Denial of Service 攻击。

示例 1：以下方法绝不会关闭它所读取的数据流。

...
CFIndex numBytes;
do {
    UInt8 buf[bufferSize];
    numBytes = CFReadStreamRead(readStream, buf, sizeof(buf));
    if( numBytes > 0 ) {
        handleBytes(buf, numBytes);
    } else if( numBytes < 0 ) {
        CFStreamError error = CFReadStreamGetError(readStream);
        reportError(error);
    }
} while( numBytes > 0 );
...

程序可能无法释放系统资源。

资源泄露至少有两种常见的原因：

- 错误状况及其他异常情况。

- 未明确程序的哪一部份负责释放资源。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起 Denial of Service 攻击。

示例：下面的方法绝不会关闭它所打开的文件句柄。

def readFile(filename: String): Unit = {
    val data = Source.fromFile(fileName).getLines.mkString
    // Use the data
}

程序可能无法释放某系统资源。


资源泄露至少有两种常见的原因：

- 错误状况及其他异常情况。

- 未明确程序的哪一部份负责释放资源。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起 Denial of Service 攻击。

示例 1：下面的方法绝不会关闭它所读取的数据流。

...
        func leak(reading input: InputStream) {
            input.open()
            let bufferSize = 1024
            let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferSize)
            while input.hasBytesAvailable {
                let read = input.read(buffer, maxLength: bufferSize)
            }
            buffer.deallocate(capacity: bufferSize)
        }
...

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

示例：以下操作方法将向外部 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);
...

如果攻击者可以提供应用程序用来确定调用哪种方法或检索哪个字段值的值，则攻击者有可能通过应用程序创建应用程序开发人员未预期的控制流路径。此攻击途径可能使攻击者可以绕过身份验证或访问控制检查，或者可能会导致应用程序以非预期方式运行。

示例 1：在此示例中，应用程序从命令行参数中检索要调用的函数的名称。

...
    func beforeExampleCallback(scope *Scope){
        input := os.Args[1]
        if input{
            scope.CallMethod(input)
        }
    }
...
    

示例 2：与之前的示例类似，应用程序使用 reflect 程序包从命令行参数中检索要调用的函数的名称。

...
    input := os.Args[1]
	var worker WokerType
	reflect.ValueOf(&worker).MethodByName(input).Call([]reflect.Value{})
...

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

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

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(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 检查。下面是一段重新修改的代码示例：

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(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 的一个共同理由是实现自己的命令发送器。下面的例子显示了一个 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 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 攻击利用 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>

当使用 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 美元的鞋。