除非页面内容完全在您的控制之下，否则用户将能够单击可能由恶意攻击者使用的链接来自动拨打电话或发起 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 应用程序代码将尝试从 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)
        }
    }

如果用户为 logout 提交字符串“twenty-one”，而且他可以创建一个名为“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 脚本中接受一个由用户提交的字符串，并试图将其转换为它所代表的长整数值。如果这个数值没能被解析成整数，那么数值会随同错误消息一起存入日志，提示发生的情况。

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 的漏洞：

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");
    }
?>

如果用户为 logout 提交字符串“twenty-one”，而且他可以创建一个名为“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))

如果用户为 logout 提交字符串“twenty-one”，而且他可以创建一个名为“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 的漏洞：

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 请求参数。因此，恶意用户能够将值分配给绑定类或嵌套类中的任意属性，即使这些属性未通过 Web 表单或 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 Web Form 应用程序中，将 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 实体框架和 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 请求参数绑定到哪些模型属性，攻击者可能会滥用模型绑定过程并设置不应向用户控件公开的任何其他属性。即使模型属性未出现在 Web 表单或 API 合约中，也可能会发生这种绑定。

例 1：以下 ASP.NET MVC 控制器方法 (Register) 从 Web 表单进行访问，该表单要求用户通过提供其姓名和密码注册帐户。

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
  .

Memory leak 的产生有两个常见（有时候这两个原因会同时发生作用）原因：

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

— 不清楚由程序的哪一部分负责释放内存。

大多数 memory leak 会导致常规软件可靠性问题，但如果攻击者能够蓄意触发 memory leak，他就可能会通过引发程序崩溃来发起一个 denial of service 攻击，或者是利用因内存低的情况 [1] 所引发的其他意外的程序行为。

例 1：该 Objective-C 对象通过 init() 方法分配内存，但无法通过 deallocate() 方法将其释放，导致 memory leak：

- (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 dereference。

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 太大，还是因为在同一时刻处理的请求太多。或者是由于已累计超时的 memory leak 引起的。如果不对错误进行处理，就不会知道是什么原因。