LDAP injection 错误在以下情况下出现：

1. 数据从一个不可信赖的数据源进入程序。

在这种情况下，Fortify Static Code Analyzer（Fortify 静态代码分析器）无法确定数据源是否可信赖。

2. 该数据用于动态构造 LDAP 筛选器。
示例 1：以下代码动态构造一个 LDAP 查询，并对其加以执行，该查询可以检索所有报告给指定经理的雇员记录。该经理的名字是从 HTTP 请求中读取的，因此不可信任。

...
DirectorySearcher src =
           new DirectorySearcher("(manager=" + managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;

foreach(SearchResult res in src.FindAll()) {
  ...
}

在正常情况下，诸如搜索向 John Smith 经理报告的雇员，该代码执行的筛选器如下：

(manager=Smith, John)

但是，由于筛选器是通过连接一个常数基本查询串和一个用户输入串动态构造而成的，因此，该查询只在 managerName 不包含任何 LDAP 元字符时才能正常运行。如果攻击者为 managerName 输入字符串 Hacker, Wiley)(|(objectclass=*)，则该查询会变成：

(manager=Hacker, Wiley)(|(objectclass=*))

根据执行查询的权限，增加 |(objectclass=*) 条件会导致筛选器与目录中的所有输入都匹配，而且会使攻击者检索到有关用户输入池的信息。根据执行 LDAP 查询的权限大小，此次攻击的影响范围可能会有所差异，但是如果攻击者可以控制查询的命令结构，那么这样的攻击至少会影响执行 LDAP 查询的用户可以访问的所有记录。

LDAP injection 错误在以下情况下出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 该数据用于动态构造 LDAP 筛选器。
示例 1：以下代码动态构造一个 LDAP 查询，并对其加以执行，该查询可以检索所有报告给指定经理的雇员记录。该经理的名字是从网络套接字中读取的，因此不可信任。

fgets(manager, sizeof(manager), socket);

snprintf(filter, sizeof(filter, "(manager=%s)", manager);

if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
       filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
       LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
  ...
}

在正常情况下，诸如搜索向 John Smith 经理报告的雇员，该代码执行的筛选器如下：

(manager=Smith, John)

但是，由于筛选器是通过连接一个常数基本查询串和一个用户输入串动态构造而成的，因此，该查询只在 manager 不包含任何 LDAP 元字符时才能正常运行。如果攻击者为 manager 输入字符串 Hacker, Wiley)(|(objectclass=*)，则该查询会变成：

(manager=Hacker, Wiley)(|(objectclass=*))

根据执行查询的权限，增加 |(objectclass=*) 条件会导致筛选器与目录中的所有输入都匹配，而且会使攻击者检索到有关用户输入池的信息。根据执行 LDAP 查询的权限大小，此次攻击的影响范围可能会有所差异，但是如果攻击者可以控制查询的命令结构，那么这样的攻击至少会影响执行 LDAP 查询的用户可以访问的所有记录。

LDAP injection 错误在以下情况下出现：
1.数据从一个不可信赖的数据源进入程序。

2.该数据用于动态构造 LDAP 筛选器。
示例 1：以下代码动态构造一个 LDAP 查询，并对其加以执行，该查询可以检索所有报告给指定经理的雇员记录。该经理的名字是从 HTTP 请求中读取的，因此不可信任。

...
$managerName = $_POST["managerName"]];

//retrieve all of the employees who report to a manager

$filter = "(manager=" . $managerName . ")";

$result = ldap_search($ds, "ou=People,dc=example,dc=com", $filter);
...

在正常情况下，诸如搜索向 John Smith 经理报告的雇员，该代码执行的筛选器如下：

(manager=Smith, John)

但是，由于筛选器是通过连接一个常数基本查询串和一个用户输入串动态构造而成的，因此，该查询只在 managerName 不包含任何 LDAP 元字符时才能正常运行。如果攻击者为 managerName 输入字符串 Hacker, Wiley)(|(objectclass=*)，则该查询会变成：

(manager=Hacker, Wiley)(|(objectclass=*))

根据执行查询的权限，增加 |(objectclass=*) 条件会导致筛选器与目录中的所有输入都匹配，而且会使攻击者检索到有关用户输入池的信息。根据执行 LDAP 查询的权限大小，此次攻击的影响范围可能会有所差异，但是如果攻击者可以控制查询的命令结构，那么这样的攻击至少会影响执行 LDAP 查询的用户可以访问的所有记录。

LDAP manipulation 错误在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据在一个动态 LDAP 指令的滤字符串之外使用。
示例 1：下面的代码会从一个通过 HTTP 请求提交的隐藏字段中读取 ou 字符串，并使用该字符串创建一个新的 DirectoryEntry。

...
de = new DirectoryEntry("LDAP://ad.example.com:389/ou="
                        + hiddenOU.Text + ",dc=example,dc=com");
...

由于连接字符串包含用户输入且在匿名捆绑下执行，因此攻击者可能会通过指定一个意外的 ou 值来篡改查询结果。问题在于开发人员没能充分利用适当的访问控制机制来限制随后的查询，使其只能读取那些允许当前用户读取的雇员记录。

LDAP manipulation 错误在以下情况中出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据在一个动态 LDAP 指令的滤字符串之外使用。
例 1：以下代码从套接字中读取 dn 字符串，然后使用该字符串来执行 LDAP 查询。

...
rc = ldap_simple_bind_s( ld, NULL, NULL );
  if ( rc != LDAP_SUCCESS ) {
    ...
  }
...

fgets(dn, sizeof(dn), socket);

if ( ( rc = ldap_search_ext_s( ld, dn, LDAP_SCOPE_BASE,
                               filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
                               LDAP_NO_LIMIT, &result ) ) != LDAP_SUCCESS ) {
...

由于基 DN 来源于用户输入，且在匿名绑定的情况下执行查询，因此攻击者可能会通过指定一个意外的 dn 字符串来篡改查询结果。问题在于开发人员没能充分利用适当的访问控制机制来限制随后的查询，使其只能读取那些允许当前用户读取的雇员记录。

LDAP manipulation 错误在以下情况中出现：

1.数据从一个不可信赖的数据源进入程序。

2.数据在一个动态 LDAP 指令的滤字符串之外使用。
示例 1：以下代码从用户处读取 dn 字符串，然后使用该字符串来执行 LDAP 查询。

$dn = $_POST['dn'];

if (ldap_bind($ds)) {
...

try {
  $rs = ldap_search($ds, $dn, "ou=People,dc=example,dc=com", $attr);
...

由于基 dn 来源于用户输入，且在匿名绑定的情况下执行查询，因此攻击者可能会通过指定一个意外的 DN 字符串来篡改查询结果。问题在于开发人员没能充分利用适当的访问控制机制来限制随后的查询，使其只能读取那些允许当前用户读取的雇员记录。

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

在以下情况下会发生 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 序列化有效负载来破坏缓存或执行任意代码。

应用程序无法验证从 Web 表单收到的数据类型。 比较好的做法是，验证收到的数据是否满足为预期数据定义的要求。


示例 1： 以下代码定义了一个表单，但是无法针对预期要求验证数据：

  def form = Form(
    mapping(
      "name" -> text,
      "age" -> number
    )(UserData.apply)(UserData.unapply)
  )

最成功的攻击往往会从违反程序员的假设开始。不经过 DTD 或 XML schema 的验证，就直接接受 XML 文档，这样一来，程序员就会为攻击者打开了一扇大门，可以向程序提供无法预测、不合理或是恶意的输入。当然，XML 解析器不可能验证文档中出现的所有内容；任何解析器都无法完全理解数据的全部语意。然而，解析器可以进行完整而彻底的检查文档结构，从而保证处理文档的代码在内容安排上的合理性。

最成功的攻击往往会从违反程序员的假设开始。不经过 DTD 或 XML schema 的校验，就直接接受 XML 文档，这样一来，程序员就会为攻击者打开了一扇大门，可以向程序提供无法预测、不合理或是恶意的输入。当然，XML 解析器不可能校验文档中出现的所有内容；任何解析器都无法完全理解数据的全部语意。然而，解析器可以进行完整而彻底的检查文档结构，从而保证处理文档的代码在内容安排上的合理性。