HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

示例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.aspx?name=alice&name=hacker

示例 2：下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

    ...
    String lang = Request.Form["lang"];
    WebClient client = new WebClient();
    client.BaseAddress = url;
    NameValueCollection myQueryStringCollection = new NameValueCollection();
    myQueryStringCollection.Add("q", lang);
    client.QueryString = myQueryStringCollection;
    Stream data = client.OpenRead(url);
    ...

URL: http://www.host.com/election.aspx?poll_id=4567
链接 1：<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">英语<a>
链接 2：<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">西班牙语<a>

程序员尚未考虑下面这种可能性：攻击者可能会提供一个 lang（例如 en&poll_id=1），然后攻击者可以随意更改该 poll_id。

HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

例 2：下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

    <%
        ...
        $id = $_GET["id"];
        header("Location: http://www.host.com/election.php?poll_id=" . $id);
        ...
    %>

URL： http://www.host.com/election.php?poll_id=4567
链接 1： <a href="vote.php?poll_id=4567&candidate=white">White 先生的投票<a>
链接 2： <a href="vote.php?poll_id=4567&candidate=green">Green 女士的投票<a>

程序员没有考虑到攻击者可能提供 poll_id（例如“4567&candidate=green”）的可能性，届时得到的页面中将包含以下注入链接，因此，Green 女士将始终投票选择捡出第一个参数的应用程序服务器。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">White 先生的投票<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Green 女士的投票<a>

HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据。
它可能从最后一个参数中提取数据。
它可能从所有参数中提取数据并把它们连接起来。


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

因为这表明，攻击者已经指定了 name=alice，但他们添加了额外的 name=alice&，如果在提取第一个匹配项的服务器上使用它，那么它可能会模仿 alice 以便获取有关她的帐户的详细信息。

键盘扩展可以读取用户输入的每一个按键。第三方键盘通常用于简化文本输入或添加额外的表情符号，他们可以记录用户输入的内容，甚至将其发送到远程服务器进行处理。恶意键盘还可以作为键盘记录器来分发，以读取用户输入的每一个键，从而窃取凭据或信用卡号等敏感数据。

在以下情况下会发生 Log Forging 的漏洞：

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

2. 数据写入到应用程序或系统日志文件中。

为了便于以后的审阅、统计数据收集或调试，应用程序通常使用日志文件来储存事件或事务的历史记录。根据应用程序自身的特性，审阅日志文件可在必要时手动执行，也可以自动执行，即利用工具自动挑选日志中的重要事件或带有某种倾向性的信息。

如果攻击者可以向随后会被逐字记录到日志文件的应用程序提供数据，则可能会妨碍或误导日志文件的解读。最理想的情况是，攻击者可能通过向应用程序提供包括适当字符的输入，在日志文件中插入错误的条目。如果日志文件是自动处理的，那么攻击者就可以通过破坏文件格式或注入意外的字符，从而使文件无法使用。更阴险的攻击可能会导致日志文件中的统计信息发生偏差。通过伪造或其他方式，受到破坏的日志文件可用于掩护攻击者的跟踪轨迹，甚至还可以牵连第三方来执行恶意行为 [1]。最糟糕的情况是，攻击者可能向日志文件注入代码或者其他命令，利用日志处理实用程序中的漏洞 [2]。

示例：下列 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]。

示例： 下列 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]。

示例：下列 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] 中的种种漏洞。

示例：以下代码从一个 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]。

示例：下面的 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]。

示例：下面的 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]。

示例：下列 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]。

示例： 下列 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]。

示例： 下列 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]。

示例：下列 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

显然，攻击者可以使用同样的机制插入任意日志条目。

这些类型的漏洞可能会在以下情况下发生：当攻击者可以影响发送到 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)
...

内存泄漏有两个共通而有时部分相同的原因：

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

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

大部分内存泄漏只会导致常规软件可靠性问题，但如果攻击者可能有意触发内存泄漏，该攻击者就有可能发起 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