在透過列印或記錄將系統資料或除錯資訊傳送至本機檔案、主控台或螢幕時，會發生內部資訊洩漏。

範例 1：以下程式碼會將堆疊追蹤列印到「除錯」主控台或記錄檔：

  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 Property Lists (plists) 等檔案及 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 Property Lists (plists) 等檔案及 SQLite 資料庫，並且可以洩露個人資訊。一般的原則是，不應將隱私相關資訊未加保護地儲存在檔案系統中。

範例：以下程式碼會將裝置識別碼列印到系統記錄檔：

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

根據系統配置，可以將資訊傾印到主控台，寫入記錄檔，或者顯示給使用者。在某些情況下，這個錯誤資訊正好可以告訴攻擊者這個系統被入侵的可能性有多大。例如，資料庫錯誤資訊即可揭露應用程式容易受到 SQL injection 攻擊。其他錯誤資訊還可揭露更多關於系統的間接線索。

在透過列印或記錄將系統資料或除錯資訊傳送至本機檔案、主控台或螢幕時，會發生內部資訊洩漏。

範例：以下程式碼會將 ASPError 物件傳送至 Script 偵錯工具 (如 Microsoft 指令碼偵錯工具)：

...
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。

處理存取控制問題的其中一個方法，就是讓 Worker 物件負責執行存取控制檢查。重新修改的程式碼的範例如下：

...
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 指令發送器從 CGI 要求中讀取一個數值來執行 Java 方法。執行此程式碼使得攻擊者可以呼叫任何在 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 權限。

處理存取控制問題的其中一個方法，就是讓 Worker 物件負責執行存取控制檢查。重新修改的程式碼的範例如下：

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，因為他們會略過安全存取檢查，從而使系統易於受遠端攻擊者的攻擊。如需有關這些 Java API 的詳細資訊，請參閱適用於 Java 程式語言的安全編碼規範之第 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 權限。

處理存取控制問題的其中一個方法，就是讓 Worker 物件負責執行存取控制檢查。重新修改的程式碼的範例如下：

	$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() 來呼叫這些方法。很難稽核和追蹤這些方法以及存取控制程式碼與之搭配使用的方式，考慮執行這些作業的時間取決於載入的其他程式庫程式碼，因此，想要以此種方式正確地執行這些作業更是難上加難。

如果攻擊者可以提供值，且應用程式會使用這些值來決定要個體化的類別或要叫用的方法，那麼攻擊者就可能可以透過應用程式，建立非應用程式開發者指定的控制流路徑。這種攻擊途徑可能會讓攻擊者避開驗證或存取控制檢查，或者使得應用程式以無法預期的方式運作。即使可以控制傳送給指定方法或建構函式的引數，老謀深算的攻擊者還是可能會取得成功發動攻擊的必要條件。

如果攻擊者可能將檔案上傳到應用程式的類別路徑中的位置，或將新項目新增到應用程式的類別路徑，則將導致應用程式陷入完全的困境。無論是以上哪種情況，攻擊者可能使用反映作用，將新的、可能的惡意行為引入應用程式。
範例：程式設計師使用反映 API 的常見原因是為了實作自己的指令發送器。以下範例顯示使用反映功能的指令發送器：

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(ctl + "Command")
    Worker ao = (Worker) cmdClass.newInstance()
    ao.doAction(request)
    ...
}

乍看之下，修改程式碼似乎能提供許多好處。程式碼的行數較少，if/else 區塊已完全刪除，且現在可以在不修改指令發送器的情況下增加新的指令類型。

但是，這樣的修改方式會讓攻擊者個體化所有會實作 Worker 介面的物件。如果指令發送器仍然負責存取控制，則無論程式設計師何時建立實作 Worker 介面的新類別，他們都必須記得要去修改發送器的存取控制程式碼。如果他們無法修改存取控制程式碼，則部分 Worker 類別將不會擁有任何存取控制。

處理存取控制問題的其中一個方法，就是讓 Worker 物件負責執行存取控制檢查。重新修改的程式碼的範例如下：

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，因為他們會略過安全存取檢查，從而使系統易於受遠端攻擊者的攻擊。如需有關這些 Java API 的詳細資訊，請參閱適用於 Java 程式語言的安全編碼規範之第 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 權限。

處理存取控制問題的其中一個方法，就是讓 Worker 物件負責執行存取控制檢查。重新修改的程式碼的範例如下：

...
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) Injection 發生於：

1. 資料從一個不可信賴的來源進入程式。

2. 該資料會寫入<ENTITY> XML 文件內 DTD (文件類型定義) 的元素。

應用程式通常使用 XML 來儲存資料或傳送訊息。應用程式會將用來儲存資料的 XML 文件視為資料庫，因此文件中可能會包含敏感資訊。XML 訊息通常用於 Web 服務，可用來傳送敏感資訊。XML 訊息甚至可用於傳送驗證憑證。

如果攻擊者有能力撰寫未經處理的 XML，即有可能修改 XML 文件和訊息的語義。在大部分不具惡意的情況下，攻擊者可能會插入巢狀實體參照並造成 XML 解析器不斷大量消耗 CPU 資源。在較為惡意的 XML External Entity Injection 情況下，攻擊者可能會新增 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 外部實體攻擊憑藉的是在處理時會動態建置文件這一 XML 功能。XML 實體允許動態納入指定資源的資料。外部實體允許 XML 文件納入外部 URI 的資料。除非另行設定，否則外部實體會強制 XML 解析器存取由 URI 指定的資源，例如本機機器或遠端系統上的檔案。此行為會導致應用程式遭受 XML 外部實體 (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 外部實體攻擊憑藉的是在執行階段會動態建置文件這一 XML 功能。XML 實體允許動態納入指定資源的資料。外部實體允許 XML 文件納入外部 URI 的資料。除非另行配置，否則外部實體會強制 XML 剖析器存取由 URI 指定的資源，例如本機機器或遠端系統上的檔案。此行為會導致應用程式遭受 XML 外部實體 (XXE) 攻擊，攻擊者可使用這類攻擊執行本機系統的阻斷服務、取得本機機器上檔案的未授權的存取權、掃描遠端機器，並執行遠端系統的阻斷服務。


範例 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) Injection 發生於：

1. 資料從一個不可信賴的來源進入程式。

2. 該資料寫入至 XML 文件內 DTD (文件類型定義) 的 <ENTITY> 元素。

應用程式通常使用 XML 來儲存資料或傳送訊息。應用程式會將用來儲存資料的 XML 文件視為資料庫，因此文件中可能會包含敏感資訊。XML 訊息通常用於 Web 服務，可用來傳送敏感資訊。XML 訊息甚至可用於傳送驗證憑證。

如果攻擊者有能力撰寫未經處理的 XML，即有可能修改 XML 文件和訊息的語義。在大部分不具惡意的情況下，攻擊者可能會插入巢狀實體參照並造成 XML 解析器不斷大量消耗 CPU 資源。在較為惡意的 XML External Entity Injection 情況下，攻擊者可能會新增 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) Injection 發生於：

1. 資料從一個不可信賴的來源進入程式。

2. 將資料寫入 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 時，<foo> 元素的內容會填入系統 boot.ini 檔案的內容。攻擊者可能利用傳回到用戶端的 XML 元素竊取資料或取得資訊，以便知道有哪些網路資源。

XML 外部實體攻擊憑藉的是在執行階段會動態建置文件這一 XML 功能。XML 實體允許動態納入指定資源的資料。外部實體允許 XML 文件納入外部 URI 的資料。除非另行配置，否則外部實體會強制 XML 剖析器存取由 URI 指定的資源，例如本機機器或遠端系統上的檔案。此行為會導致應用程式遭受 XML 外部實體 (XXE) 攻擊，攻擊者可使用這類攻擊執行本機系統的阻斷服務、取得本機機器上檔案的未授權的存取權、掃描遠端機器，並執行遠端系統的阻斷服務。


範例 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 外部實體攻擊憑藉的是在處理時會動態建置文件這一 XML 功能。XML 實體允許動態納入指定資源的資料。外部實體允許 XML 文件納入外部 URI 的資料。除非另行配置，否則外部實體會強制 XML 解析器存取由 URI 指定的資源，例如本機機器或遠端系統上的檔案。此行為會導致應用程式遭受 XML 外部實體 (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) Injection 發生於：

1. 資料從一個不可信賴的來源進入程式。

2. 該資料寫入至 XML 文件內 DTD (文件類型定義) 的 <ENTITY> 元素。

應用程式通常使用 XML 來儲存資料或傳送訊息。應用程式會將用來儲存資料的 XML 文件視為資料庫，因此文件中可能會包含敏感資訊。XML 訊息通常用於 Web 服務，可用來傳送敏感資訊。XML 訊息甚至可用於傳送驗證憑證。

如果攻擊者有能力撰寫未經處理的 XML，即有可能修改 XML 文件和訊息的語義。在大部分不具惡意的情況下，攻擊者可能會插入巢狀實體參照並造成 XML 解析器不斷大量消耗 CPU 資源。在較為惡意的 XML External Entity Injection 情況下，攻擊者可能會新增 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 訊息通常用於 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>

現在假設此 XML 包含在要求訂購一雙鞋子的後端 Web 服務要求中。假設攻擊者修改其要求並以 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 訊息通常用於 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>

現在假設此 XML 包含在要求訂購一雙鞋子的後端 Web 服務要求中。假設攻擊者修改其要求並以 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 訊息通常用於 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>

現在假設此 XML 包含在要求訂購一雙鞋子的後端 Web 服務要求中。假設攻擊者修改其要求並以 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 訊息通常用於 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>

現在假設此 XML 包含在要求訂購一雙鞋子的後端 Web 服務要求中。假設攻擊者修改其要求並以 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 訊息通常用於 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>

現在假設此 XML 包含在要求訂購一雙鞋子的後端 Web 服務要求中。假設攻擊者修改其要求並以 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 美元的鞋子。