除非該頁面的內容完全由您掌控，否則使用者將能夠點選惡意攻擊者可能用來啟動自動電話或 FaceTime 通話的連結。

舉例來說，您的應用程式可能會顯示部落格貼文或推文，其中可能包含連結。您的使用者所造訪的貼文或推文的作者能夠在其頁面上使用任意連結。如果您的使用者造訪惡意網站並遭受欺騙，或者自動被迫按一下某個連結，則攻擊者能夠啟動自動 FaceTime 或電話通話，然後將裝置封鎖幾秒鐘時間以防使用者取消通話。請注意，即使您控制了登陸頁面，使用者最終仍可能會導覽到其他不可信賴的網站。

範例 1：以下程式碼片段使用 webview 來載入可能包含不可信賴連結的網站，但未指定能夠驗證此 webview 中啟動的要求的委派：

    ...
    let webUrl : NSURL = NSURL(string: "https://some.site.com/")!
    let webRequest : NSURLRequest = NSURLRequest(URL: webUrl)
    webView.loadRequest(webRequest)
    ...

除非該頁面的內容完全由您掌控，否則使用者將能夠點選惡意攻擊者可能用來啟動所不希望的動作的連結。

舉例來說，您的應用程式可能會顯示部落格貼文或推文，其中可能包含連結。您的使用者所造訪的貼文或推文的作者能夠在其頁面上使用任意連結。如果您的使用者造訪惡意網站後遭受欺騙，或者自動被迫按一下某個連結，則攻擊者能夠啟動某些可能有危險的動作，例如使用特殊 URL 架構來啟動 FaceTime 或電話通話、傳送資料或是在第三方應用程式中啟動動作等。請注意，即使您控制了登陸頁面，使用者最終仍可能會導覽到其他不可信賴的網站。

範例 1：以下程式碼片段使用 webview 來載入可能包含不可信賴連結的網站，但未指定能夠驗證此 webview 中啟動的要求的委派：

    ...
    let webUrl = URL(string: "https://some.site.com/")!
    let urlRequest = URLRequest(url: webUrl)
    webView.load(webRequest)
    ...

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取數值。然後記錄此數值。

...
DATA log_msg TYPE bal_s_msg.

val = request->get_form_field( 'val' ).

log_msg-msgid = 'XY'.
log_msg-msgty = 'E'.
log_msg-msgno = '123'.
log_msg-msgv1 = 'VAL: '.
log_msg-msgv2 = val.

CALL FUNCTION 'BAL_LOG_MSG_ADD'
  EXPORTING
    I_S_MSG          = log_msg
  EXCEPTIONS
    LOG_NOT_FOUND    = 1
    MSG_INCONSISTENT = 2
    LOG_IS_FULL      = 3
    OTHERS           = 4.
...

如果使用者提交用於 val 的字串「FOO」，則會記錄以下項目：

XY E 123 VAL: FOO

不過，如果攻擊者傳遞了字串「FOO XY E 124 VAL: BAR」，則會記錄以下的項目：

XY E 123 VAL: FOO XY E 124 VAL: BAR

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var val:String = String(params["username"]);
var value:Number = parseInt(val);
if (value == Number.NaN) {
  trace("Failed to parse val = " + val);
}

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

Failed to parse val=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

Failed to parse val=twenty-one

User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2.資料寫入至應用程式或是系統記錄檔中。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

...
string val = (string)Session["val"];
try {
int value = Int32.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val= " + val);
}
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 資料被寫入應用程式或系統日誌檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質，日誌檔可以在需要的時候手動地進行檢索，或者藉由使用工具自動地進行檢索，以得到重要的資料點以及資料趨勢。

如果一個攻擊者能給應用程式提供隨後會被逐字記錄到記錄檔的資料資訊，記錄檔的檢查可能會被妨礙，甚至基於記錄資料的總結可能是錯誤的。攻擊者能夠在他們的資料中包含記錄項目分隔符號字元的話，那他們就可以在記錄中插入錯誤的項目資訊。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。在最糟糕的情況中，攻擊者可以在記錄檔中注入程式碼或者其他的指令，充分利用記錄處理公用程式的弱點 [2]。

範例 1：以下程式碼從一個 CGI 指令碼中接收一個由使用者提交的字串，並試圖將其轉換為長整數值。如果該數值無法解析為整數，則會記錄其值並顯示錯誤訊息，指出發生了什麼情況。

long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
	syslog(LOG_INFO,"Illegal value = %s",val);
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

Illegal value=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one\n\nINFO: User logged out=evil」，則會記錄以下的項目：

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

很顯然，攻擊者可能使用此相同的機制來插入任意記錄項目。為了使這種類型的 log forging 攻擊更有效，攻擊者必須首先定義有效的記錄項目格式，但是這通常是以應用程式的系統資訊洩露為代價的。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由向應用程式提供包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可以藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔處理公用程式的弱點進行破壞 [2]。

範例 1：以下的 Web 應用程式程式碼嘗試從 HTML 表單中讀取數值。然後記錄此數值。

...
01  LOGAREA.
     05  VALHEADER        PIC X(50) VALUE 'VAL: '.
     05  VAL              PIC X(50).
...

EXEC CICS
  WEB READ
  FORMFIELD(NAME)
  VALUE(VAL)
  ...
END-EXEC.

EXEC DLI
  LOG
  FROM(LOGAREA)
  LENGTH(50)
END-EXEC.
...

如果使用者提交用於 VAL 的字串「FOO」，則會記錄以下項目：

VAL: FOO

不過，如果攻擊者傳遞了字串「FOO VAL: BAR」，則會記錄以下的項目：

VAL: FOO VAL: BAR

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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


2. 將資料寫入應用程式或系統記錄檔。


一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下的 Web 應用程式程式碼嘗試從網頁表單中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

<cflog file="app_log" application="No" Thread="No" 
       text="Failed to parse val="#Form.val#">

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

不過，如果攻擊者傳遞了字串「twenty-one%0a%0a%22Information%22%2C%2C%2202/28/01%22%2C%2214:53:40%22%2C%2C%22User%20logged%20out:%20badguy%22」，則會記錄以下的項目：

"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

"Information",,"02/28/01","14:53:40",,"User logged out: badguy"

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2.將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件的歷史記錄、檢視交易以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱記錄檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由向應用程式提供包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就有可能藉由破壞檔案格式或插入預期外字元的方式，使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔處理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        name := r.FormValue("name")
        logout := r.FormValue("logout")
        ...
        if (logout){
            ...
        } else {
            log.Printf("Attempt to log out: name: %s logout: %s", name, logout)
        }
    }

如果使用者提交字串「twenty-one」給 logout，且能夠建立名稱為「admin」的使用者，則會記錄以下項目：

Attempt to log out: name: admin logout: twenty-one

不過，若攻擊者能建立「admin+logout:+1+++++++++++++++++++++++」這個使用者名稱，則會記錄以下項目：

Attempt to log out: name: admin logout: 1                       logout: twenty-one

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一個錯誤訊息，說明發生哪些情況。

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var val = url.parse(request.url, true)['query']['val'];
  if (isNaN(val)){
    console.log("INFO: Failed to parse val = " + val);
  }
  ...
}
...
http.createServer(listener).listen(8080);
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val = twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質，日誌檔可以在需要的時候手動地進行檢索，或者藉由使用工具自動地進行檢索，以得到重要的資料點以及資料趨勢。

如果一個攻擊者能給應用程式提供隨後會被逐字記錄到記錄檔的資料資訊，記錄檔的檢查可能會被妨礙，甚至基於記錄資料的總結可能是錯誤的。攻擊者能夠在他們的資料中包含記錄項目分隔符號字元的話，那他們就可以在記錄中插入錯誤的項目資訊。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。在最糟糕的情況中，攻擊者可以在記錄檔中注入程式碼或者其他的指令，充分利用記錄處理公用程式的弱點 [2]。

範例 1：以下程式碼從一個 CGI script 中接收一個由使用者提交的字串，並試圖將其轉換為長整型的數值。如果這個數值沒能被解譯成一個數位，那麼輸入資訊就會存入記錄，提示錯誤。

long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
	NSLog("Illegal value = %s",val);
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

    INFO: Illegal value=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one\n\nINFO: User logged out=evil」，則會記錄以下的項目：

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

很顯然，攻擊者可能使用此相同的機制來插入任意記錄項目。為了使這種類型的 Log Forging 攻擊有效，攻擊者必須首先識別有效的記錄項目格式，但這通常是以目標應用程式的系統資訊洩漏為代價的。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

<?php
    $name   =$_GET['name'];
    ...
    $logout =$_GET['logout'];

    if(is_numeric($logout))
    {
        ...
    }
    else
    {
        trigger_error("Attempt to log out: name: $name logout: $val");
    }
?>

如果使用者提交字串「twenty-one」給 logout，且能夠建立名稱為「admin」的使用者，則會記錄以下項目：

PHP Notice: Attempt to log out: name: admin logout: twenty-one

不過，若攻擊者能建立「admin+logout:+1+++++++++++++++++++++++」這個使用者名稱，則會記錄以下項目：

PHP Notice: Attempt to log out: name: admin logout: 1                       logout: twenty-one

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

    name = req.field('name')
    ...
    logout = req.field('logout')

    if (logout):
        ...
    else:
        logger.error("Attempt to log out: name: %s logout: %s" % (name,logout))

如果使用者提交字串「twenty-one」給 logout，且能夠建立名稱為「admin」的使用者，則會記錄以下項目：

Attempt to log out: name: admin logout: twenty-one

不過，若攻擊者能建立「admin+logout:+1+++++++++++++++++++++++」這個使用者名稱，則會記錄以下項目：

Attempt to log out: name: admin logout: 1                       logout: twenty-one

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一個錯誤訊息，說明發生哪些情況。

...
val = req['val']
unless val.respond_to?(:to_int)
  logger.info("Failed to parse val")
  logger.info(val)
end
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val
INFO: twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

INFO: Failed to parse val
INFO: twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質，日誌檔可以在需要的時候手動地進行檢索，或者藉由使用工具自動地進行檢索，以得到重要的資料點以及資料趨勢。

如果一個攻擊者能給應用程式提供隨後會被逐字記錄到記錄檔的資料資訊，記錄檔的檢查可能會被妨礙，甚至基於記錄資料的總結可能是錯誤的。攻擊者能夠在他們的資料中包含記錄項目分隔符號字元的話，那他們就可以在記錄中插入錯誤的項目資訊。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。在最糟糕的情況中，攻擊者可以在記錄檔中注入程式碼或者其他的指令，充分利用記錄處理公用程式的弱點 [2]。

範例 1：以下程式碼接受一個由使用者提交的字串，並嘗試將其轉換為所表示的整數值。如果這個數值沒能被解譯成一個數位，那麼輸入資訊就會存入記錄，提示錯誤。

...
let num = Int(param)
if num == nil {
    NSLog("Illegal value = %@", param)
}
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

    INFO: Illegal value = twenty-one

不過，如果攻擊者傳遞了字串「twenty-one\n\nINFO: User logged out=evil」，則會記錄以下的項目：

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

很顯然，攻擊者可能使用此相同的機制來插入任意記錄項目。為了使這種類型的 Log Forging 攻擊有效，攻擊者必須首先識別有效的記錄項目格式，但這通常是以目標應用程式的系統資訊洩漏為代價的。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

...
Dim Val As Variant
Dim Value As Integer
Set Val = Request.Form("val")
If IsNumeric(Val) Then
	Set Value = Val
Else
	App.EventLog "Failed to parse val=" & Val, 1
End If
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

Failed to parse val=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0a+User+logged+out%3dbadguy」，則會記錄以下的項目：

Failed to parse val=twenty-one

User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

1.資料從不受信任的來源進入應用程式。



2.將資料寫入應用程式或系統記錄檔。



一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱記錄檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由向應用程式提供包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就有可能藉由破壞檔案格式或插入預期外字元的方式，使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔處理公用程式的弱點進行破壞 [2]。

範例 1：以下 REST 端點嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

@HttpGet
global static void doGet() {
    RestRequest req = RestContext.request;
    String val = req.params.get('val');
    try {
        Integer i = Integer.valueOf(val);
        ...
    } catch (TypeException e) {
        System.Debug(LoggingLevel.INFO, 'Failed to parse val: '+val);
    }
}

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

Failed to parse val: twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aUser+logged+out%3dbadguy」，則會記錄以下項目：

Failed to parse val: twenty-one

User logged out=badguy

您可以清楚發現，攻擊者可使相同的機制來插入任意記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。 根據應用程式的本質而定，檢閱記錄檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。 在大多數理想的情況下，攻擊者可能會藉由向應用程式提供包含適當字元的輸入，而將錯誤的項目插入記錄檔。 如果記錄檔是自動化處理的，那麼攻擊者就有可能藉由破壞檔案格式或插入預期外字元的方式，使檔案無法使用。 更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。 藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。 最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔處理公用程式的弱點進行破壞 [2]。

範例 1： 以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。 如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一條錯誤訊息，說明發生哪些情況。

  ...
          String val = request.Params["val"];
          try {
                  int value = Int.Parse(val);
          }
          catch (FormatException fe) {
                  log.Info("Failed to parse val = " + val);
          }
  ...
  

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

  INFO: Failed to parse val=twenty-one
  

不過，如果攻擊者提交字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下項目：

  INFO: Failed to parse val=twenty-one

  INFO: User logged out=badguy
  

您可以清楚地發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如 Log Forging) 不會產生影響，因為使用者為何會攻擊自己呢？ 但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。 在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 2：以下程式碼改寫 Example 1 以適用於 Android 平台。

  ...
          String val = this.Intent.Extras.GetString("val");
          try {
                  int value = Int.Parse(val);
          }
          catch (FormatException fe) {
                  Log.E(TAG, "Failed to parse val = " + val);
          }
  ...
  

Log Forging 弱點會在以下情況中出現：

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

2.將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱記錄檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由向應用程式提供包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可以藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，攻擊者可能使用毀損的記錄檔來掩護其追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔處理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一則錯誤訊息，說明發生哪些情況。

...
    var idValue string

    idValue = req.URL.Query().Get("id")
    num, err := strconv.Atoi(idValue)

    if err != nil {
        sysLog.Debug("Failed to parse value: " + idValue)
    }
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val=twenty-one

不過，如果攻擊者提交字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下項目：

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可使相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一個錯誤訊息，說明發生哪些情況。

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var val = url.parse(request.url, true)['query']['val'];
  if (isNaN(val)){
    console.error("INFO: Failed to parse val = " + val);
  }
  ...
}
...
http.createServer(listener).listen(8080);
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一個錯誤訊息，說明發生哪些情況。

...
val = request.GET["val"]
try:
  int_value = int(val)
except:
  logger.debug("Failed to parse val = " + val)
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

INFO: Failed to parse val=twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」，則會記錄以下的項目：

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

Log Forging 弱點會在以下情況中出現：

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

2. 將資料寫入應用程式或系統記錄檔。

一般來說，應用程式會使用記錄檔來儲存事件或交易的歷史記錄，以便之後進行檢閱、統計資料蒐集或除錯之用。根據應用程式的本質而定，檢閱日誌檔的工作可在需要時手動執行，或者自動執行，方法為使用工具自動選取重要事件或帶有某種傾向資訊的記錄檔。

如果攻擊者可以提供資料給會持續逐字記錄內容的應用程式，則可能會妨礙或是誤導記錄檔的解讀。在大多數理想的情況下，攻擊者可能會藉由提供應用程式包含適當字元的輸入，而將錯誤的項目插入記錄檔。如果記錄檔是自動化處理的，那麼攻擊者就可能能夠藉由破壞檔案格式或插入預期外字元的方式，來使檔案無法使用。更猛烈的惡意攻擊甚至可能導致記錄檔的統計資料產生偏差。藉由偽造或其他方式，毀損的記錄檔可用來掩護攻擊者的追蹤，或甚至授意第三方執行惡意行為 [1]。最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼或其他指令，並利用記錄檔理公用程式的弱點進行破壞 [2]。

範例 1：以下 Web 應用程式程式碼嘗試從一個要求物件中讀取整數值。如果這個值無法解析成一個整數，那麼就會記錄此輸入並附帶一個錯誤訊息，說明發生哪些情況。

...
val = req['val']
unless val.respond_to?(:to_int)
  logger.debug("Failed to parse val")
  logger.debug(val)
end
...

如果使用者提交用於 val 的字串「twenty-one」，則會記錄以下項目：

DEBUG: Failed to parse val
DEBUG: twenty-one

不過，如果攻擊者傳遞了字串「twenty-one%0a%DEBUG:+User+logged+out%3dbadguy」，則會記錄以下的項目：

DEBUG: Failed to parse val
DEBUG: twenty-one

DEBUG: User logged out=badguy

您可以清楚發現，攻擊者可能使用相同的機制來插入任何記錄檔項目。

這些類型的弱點可能會在以下情況中出現：在攻擊者可以影響傳送至 SMTP 郵件伺服器的指令時，會發生 SMTP Command Injection 弱點。

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

2.資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3.透過執行 SMTP 命令，攻擊者可以指示伺服器執行惡意動作，例如傳送垃圾郵件。

範例 1：以下程式碼使用 HTTP 要求參數修改傳送至 SMTP 伺服器的 VRFY 指令。攻擊者可能使用此參數修改傳送至伺服器的指令，並使用 CRLF 字元插入新指令。

  ...
    c, err := smtp.Dial(x)
	if err != nil {
		log.Fatal(err)
	}
	user := request.FormValue("USER")
	c.Verify(user)
  ...
  

在攻擊者可能影響傳送至 SMTP 郵件伺服器的指令時，會發生 SMTP Command Injection 弱點。

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

2. 資料被用作代表應用程式所執行指令的字串，或字串的一部分。

3. 透過執行 SMTP 指令，攻擊者能夠指示伺服器執行惡意動作，如傳送垃圾郵件。

範例 1：以下程式碼使用 HTTP 要求參數修改傳送至 SMTP 伺服器的 VRFY 指令。攻擊者可能使用此參數修改傳送至伺服器的指令，並使用 CRLF 字元插入新指令。

...
user = request.GET['user']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
session.docmd("VRFY", user)
...

為了簡化開發並提高生產力，大多數的現代架構都允許自動個體化物件，並填入名稱與要繫結之類別的屬性相符的 HTTP 要求參數。自動個體化並填入物件可以加速開發，但是如果實作不慎，就可能會導致嚴重問題。已繫結類別或巢狀類別中的任何屬性將會自動繫結至 HTTP 要求參數。因此，惡意的使用者便能夠將值指派給已繫結或巢狀類別中的任何屬性，即使這些類別並未透過網頁表單或 API 約定而暴露給用戶端。

範例 1：在沒有其他組態的情況下，以下 ASP.NET MVC 控制項方法會將 HTTP 要求參數繫結至 RegisterModel 或 Details 類別中的任何屬性：

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

其中 RegisterModel 類別定義為：

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

而 Details 類別定義為：

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

範例 2：在 ASP.NET MVC 或 Web API 應用程式中使用 TryUpdateModel() 或 UpdateModel() 時，模型繫結器會根據預設，自動嘗試繫結所有 HTTP 要求參數：

public ViewResult Register()
{
    var model = new RegisterModel();
    TryUpdateModel<RegisterModel>(model);
    return View("detail", model);
}

範例 3：在 ASP.NET 網頁表單應用程式中，使用 TryUpdateModel() 或 UpdateModel() 搭配 IValueProvider 介面時，模型繫結器會自動嘗試繫結所有 HTTP 要求參數。

Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext)); 
if (ModelState.IsValid)
{
    db.SaveChanges();
}

而 Employee 類別定義為：

 public class Employee
    {
        public Employee()
        {
            IsAdmin = false;
            IsManager = false;
        }
        public string Name { get; set; }
        public string Email { get; set; }
        public bool IsManager { get; set; }
        public bool IsAdmin { get; set; }
    }

模型物件是以物件導向表示的資料庫實體。它們提供簡便的方法來載入、儲存、更新及刪除相關聯的資料庫實體。
Hibernate、Microsoft .NET Entity framework 及 LINQ 都是物件關係對應 (ORM) 架構的範例，可協助您建置資料庫支援的模型物件。

許多 Web 框架都提供了某種機制，用於根據對要求參數名稱與模型物件參數名稱的比對 (根據相符的公用 getter 與 setter 方法)，將要求參數繫結至要求繫結的物件，以努力減輕開發人員的工作負擔。

若應用程式使用 ORM 類別做為要求繫結的物件，則也許要求參數能修改對應模型物件中的任何欄位，以及物件屬性的任何巢狀欄位。

範例 1：Order、Customer 和 Profile 都是 Microsoft .NET 實體持續性類別。

public class Order {
	public string ordered { get; set; }
	public List<LineItem> LineItems { get; set; }
	pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
	public int CustomerId { get; set; }
	...
	public virtual Profile Profile { get; set; }
...
}
public class Profile {
	public int profileId { get; set; }
	public string username { get; set; }
	public string password { get; set; }
	...
}

OrderController 則是處理要求的 ASP.NET MVC 控制項類別：

public class OrderController : Controller{
	StoreEntities db = new StoreEntities();
...

	public String updateOrder(Order order) {
		...
		db.Orders.Add(order);
		db.SaveChanges();
	}
}

因為模型實體類別會自動繫結至要求，所以攻擊者可能利用此弱點，透過將下列要求參數新增到要求來更新另一名使用者的密碼："http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

現代的架構允許開發人員同時從要求查詢與主體，將 HTTP 要求參數自動繫結至模型物件，以簡化開發並提高生產力。如果未正確配置繫結器來控制繫結哪些 HTTP 要求參數至哪些模型屬性，則攻擊者可能會濫用模型繫結程序，並設定不應暴露給使用者控制的任何其他屬性。即使模型屬性不會出現在網頁表單或 API 約定中，這種繫結也是可能會發生。

範例 1：以下的 ASP.NET MVC 控制項方法 (Register) 會從網頁表單存取，此表單會要求使用者提供名稱及密碼來註冊帳戶：

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

其中 RegisterModel 類別定義為：

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

而 Details 類別定義為：

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

根據 Example 1 中的情況，攻擊者可能會探索應用程式並發現 RegisterModel 模型中有一個 Details 屬性。若是如此，攻擊者接著可能會嘗試覆寫指派給其屬性的目前值。
如果攻擊者能找到這些內部屬性，而架構繫結器未正確配置以禁止繫結這些屬性，則攻擊者將可以傳送以下要求來註冊管理員帳戶：

name=John&password=****&details.is_admin=true

在以下情況下會發生 Memcached injection 錯誤：

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



2. 資料用來動態建構 Memcached 索引鍵或值。

範例 1：以下程式碼會動態建構 Memcached 索引鍵。

...
def store(request):
    id = request.GET['id']
    result = get_page_from_somewhere()
    response = HttpResponse(result)
    cache_time = 1800
    cache.set("req-" % id, response, cache_time)
    return response
...

此程式碼欲執行的作業如下所示：

set req-1233 0 0 n
<serialized_response_instance>

然而，由於是透過串聯常數索引鍵字首和使用者輸入字串來動態建構該作業，因此，攻擊者可能傳送 ignore 0 0 1\r\n1\r\nset injected 0 3600 10\r\n0123456789\r\nset req- 字串，然後作業會變成如下所示：

set req-ignore 0 0 1
1
set injected 0 3600 10
0123456789
set req-1233 0 0 n
<serialized_response_instance>

上述索引鍵將在 injected=0123456789 快取中成功新增索引鍵/值組。視裝載而定，攻擊者將能夠透過插入由 Pickle 序列化的裝載 (在還原序列化之後會執行任意程式碼)，破壞快取或執行任意程式碼。

記憶體洩漏有兩個常見且有時重疊的原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部分負責釋放記憶體。

大多數的記憶體洩漏會導致一般的軟體可靠性問題，但是如果攻擊者蓄意觸發記憶體洩漏，則攻擊者可能可以發動 Denial of Service 攻擊 (透過使程式當機的方式)，或利用由記憶不足狀況導致的其他意外程式行為[1]。

範例 1：如果發生錯誤，以下 Micro Focus COBOL 程式將會洩漏配置的記憶體區塊：

  CALL "CBL_ALLOC_MEM"
      USING mem-pointer
      BY VALUE mem-size
      BY VALUE flags
      RETURNING status-code
  END-CALL

  IF status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      SET ADDRESS OF mem TO mem-pointer
  END-IF

  PERFORM write-data
  IF ws-status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      DISPLAY "Success!"
  END-IF

  CALL "CBL_FREE_MEM"
      USING BY VALUE mem-pointer
      RETURNING status-code
  END-CALL

  GOBACK
  .

記憶體洩露有兩個常見的原因 (有時這兩個原因會一起出現)：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

大部分記憶體洩漏會導致一般軟體可靠性問題，但是如果攻擊者能夠蓄意觸發資源的洩漏，攻擊者就可能會發動阻斷服務攻擊 (藉由損壞程式)，或利用因記憶體不足的狀況 [1] 導致的其他非預期程式行為。

範例 1：Objective-C 物件在 init() 方法中分配了記憶體，但無法在 deallocate() 方法中將其釋放，導致記憶體洩露：

- (void)init
{
    myVar = [NSString alloc] init];
    ...
}

- (void)dealloc
{
    [otherVar release];
}

記憶體洩漏有兩個常見且有時重疊的原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部分負責釋放記憶體。

大多數的記憶體洩漏會導致一般的軟體可靠性問題，但是如果攻擊者蓄意觸發記憶體洩漏，則攻擊者可能可以發動 Denial of Service 攻擊 (透過使程式當機的方式)，或利用由記憶不足狀況導致的其他意外程式行為[1]。

範例 1：如果對 realloc() 的呼叫未能調整原始配置的大小，則以下 Micro Focus COBOL 程式就會洩漏配置的記憶體區塊。

CALL "malloc" USING
    BY VALUE mem-size
    RETURNING mem-pointer
END-CALL

ADD 1000 TO mem-size

CALL "realloc" USING
    BY VALUE mem-pointer
    BY VALUE mem-size
    RETURNING mem-pointer
END-CALL

IF mem-pointer <> null
    CALL "free" USING
        BY VALUE mem-pointer
    END-CALL
END-IF

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼在呼叫 Equals() 成員函數前，不會檢查 Item 屬性回傳的字串是否為 null，可能會造成 null 解除參照。

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

通常對此編碼錯誤的辯解為：

「我知道要求的值會永遠存在，因為…如果這個值不存在，程式就無法執行想要的運作方式，所以無論是我處理這個錯誤或是只要讓程式停止解除參照 null 值都沒有關係。

但是，攻擊者對於在程式中尋找意料之外的情況十分在行，特別是牽涉到異常的時候。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼中，在使用由 malloc() 回傳的指標之前，並不會檢查記憶體是否已成功分配。

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

通常對此編碼錯誤的辯解為：

「如果我的程式耗盡了所有的記憶體的話，它將必定會失敗。當程式試圖忽略一個 Null 指標時，無論是我處理這個錯誤，還是只是簡單讓程式由於程式分段錯誤而自行崩潰都沒什麼關係。」

但是這個藉口忽略了以下三個重要的因素：

- 視應用程式的類型以及大小而定，在釋放記憶體的同時，該記憶體在別處正在被其他程式函數使用，而這不會影響其他程式函數的正常執行。

- 程式無法在需要時執行正常結束。如果程式執行不可部分完成的作業，它會使系統處於不一致狀態。

- 程式設計師失去了記錄診斷資訊的機會。對 malloc() 呼叫的失敗是由於 req_size 太大，或者因為在同一時刻有太多的要求需要被處理？或者是由於建立已久的記憶體洩露所引起的？若不處理此錯誤，我們將永遠不知道答案。