以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 cookie 头文件中。

...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

缓存中毒： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

Cookie Manipulation 漏洞会在以下情况下发生：

1.数据通过不可信数据源进入 Web 应用程序，最常见的是通过 HTTP 请求。



2.数据包含在未经验证就发送给 Web 用户的 HTTP Cookie 中。



如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与 Cross-Site Request Forgery 等类似攻击相结合时，攻击者可能会篡改、添加甚至覆盖合法用户的 Cookie。

作为 HTTP 响应标头，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞，该应用程序必须允许将包含 CR（回车符，也可以由 %0d 或 \r 指定）和 LF（换行符，也可以由 %0a 或 \n 指定）字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头中注入恶意字符。例如，如果尝试使用被禁用的字符设置标头，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例 1：以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 Cookie 标头中。

...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 Cookie 值来源于未经校验的用户输入，所以仅当提交给 author 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应将被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，该请求将导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning：如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响将仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应。因此，针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Open Redirect：如果允许未验证的输入控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 Cookie 头文件中。

protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

缓存中毒：如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 cookie 头文件中。

  <cfcookie name = "author"
  value = "#Form.author#"
  expires = "NOW">  

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......"，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

Cookie Manipulation 漏洞会在以下情况下发生：

1.数据通过不可信来源进入 Web 应用程序，最常见的是 HTTP 请求。

2.数据包含在未经验证就发送给 Web 用户的 HTTP Cookie 中。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似 Cross-Site Request Forgery 的攻击相结合时，攻击者就可以篡改、添加甚至覆盖合法用户的 Cookie。

作为 HTTP 响应标头，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功实施 HTTP Response Splitting 漏洞，该应用程序必须允许将包含 CR（回车符，也可以由 %0d 或 \r 指定）和 LF（换行符，也可以由 %0a 或 \n 指定）字符的输入包含在标头中。攻击者不仅可以利用这些字符控制应用程序要发送的响应的剩余标头和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 标头感染恶意字符。例如，如果尝试使用被禁用的字符设置标头，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。

示例：以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 Cookie 标头中。

...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
  Name:       "author",
  Value:      author,
  Domain:     "www.example.com",
}
http.SetCookie(w, &cookie)
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 Cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning：如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：攻击者控制了应用程序传送的响应后，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，攻击者还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会产生两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应。因此，针对受害者的这一响应中会包含所有标头或正文中的敏感信息。

Open Redirect：如果允许未验证的输入控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

例 1：下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 cookie 头文件中。

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

有些人认为在移动世界中，典型的 Web 应用程序漏洞（如头文件和 Cookie Manipulation）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。

示例 2：以下代码会调整Example 1 以适应 Android 平台。

...
	CookieManager webCookieManager = CookieManager.getInstance();
        String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
	String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
        webCookieManager.setCookie(url, setCookie);

...

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

缓存中毒： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

打开重定向：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 cookie 头文件中。

author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......"，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，该请求将导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：下列代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 cookie 头文件中。

<?php
    $author = $_GET['AUTHOR_PARAM'];
    ...
    header("author: $author");
?>

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......"，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Header Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP 响应头文件里，未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Header Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：一个攻击者将恶意数据传送到易受攻击的应用程序，且该应用程序将数据包含在 HTTP 响应头文件中。

其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：下段代码会从 HTTP 请求读取位置，并将其设置到 HTTP 响应的位置字段的头文件中。

    location = req.field('some_location')
    ...
    response.addHeader("location",location)

假设在请求中提交了一个由标准字母数字字符组成的字符串，如“index.html”，则包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
location: index.html
...

然而，因为该位置的值由未经验证的用户输入组成，所以仅当提交给 some_location 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“index.html\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

Cache Poisoning： 如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

以下情况中会出现 Cookie Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。

2. 数据包含在一个 HTTP Cookie 中，该 Cookie 未经验证就发送给了 Web 用户。

如同许多软件安全漏洞一样，Cookie Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 HTTP Cookie 中。

Cookie Manipulation：当与类似跨站请求伪造的攻击相结合时，攻击者就可以篡改、添加、甚至覆盖合法用户的 cookie。

作为 HTTP 响应头文件，Cookie Manipulation 攻击也可导致其他类型的攻击，例如：

HTTP Response Splitting：
其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。为了成功地实施 HTTP Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。

如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。例如，如果尝试使用被禁用的字符设置头文件，最新版本的 Apache Tomcat 会抛出 IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。

示例：以下代码片段会从 HTTP 请求中读取网络日志项的作者名字 author，并将其置于一个 HTTP 响应的 Cookie 头文件中。

...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...

假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如“Jane Smith”，那么包含该 Cookie 的 HTTP 响应可能表现为以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

然而，因为 cookie 值来源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

显然，第二个响应已完全由攻击者控制，攻击者可以用任何所需标头和正文内容构建该响应。攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击，包括：cross-user defacement、web and browser cache poisoning、cross-site scripting 和 page hijacking。

Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。

缓存中毒：如果多用户 Web 缓存或者单用户浏览器缓存将恶意构建的响应缓存起来，该响应的破坏力会更大。如果响应缓存在共享的 Web 缓存（如在代理服务器中常见的缓存）中，那么使用该缓存的所有用户都会不断收到恶意内容，直到清除该缓存项为止。同样，如果响应缓存在单个用户的浏览器中，那么在清除该缓存项以前，该用户会不断收到恶意内容。然而，影响仅局限于本地浏览器的用户。

Cross-Site Scripting：一旦攻击者控制了应用程序传送的响应，就可以选择多种恶意内容并将其传播给用户。Cross-Site Scripting 是最常见的攻击形式，这种攻击在响应中包含了恶意的 JavaScript 或其他代码，并在用户的浏览器中执行。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私有数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。对于易受攻击的应用程序用户，最常见且最危险的攻击就是使用 JavaScript 将会话和身份验证信息返回给攻击者，而后攻击者就可以完全控制受害者的帐号了。

Page Hijacking：除了利用一个易受攻击的应用程序向用户传输恶意内容，还可以利用相同的根漏洞，将服务器生成的供用户使用的敏感内容重定向，转而供攻击者使用。攻击者通过提交一个会导致两个响应的请求，即服务器做出的预期响应和攻击者创建的响应，致使某个中间节点（如共享的代理服务器）误导服务器所生成的响应，将本来应传送给用户的响应错误地传给攻击者。因为攻击者创建的请求产生了两个响应，第一个被解析为针对攻击者请求做出的响应，第二个则被忽略。当用户通过同一 TCP 连接发出合法请求时，攻击者的请求已经在此处等候，并被解析为针对受害者这一请求的响应。这时，攻击者将第二个请求发送给服务器，代理服务器利用针对受害者（用户）的、由该服务器产生的这一请求对服务器做出响应，因此，针对受害者的这一响应中会包含所有头文件或正文中的敏感信息。

Open Redirect：如果允许未验证的输入来控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下配置显示了如何使用通配符指定允许与应用程序进行通信的域。

  <configuration>
   <system.webServer>
     <httpProtocol>
       <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*" />
       </customHeaders>
     </httpProtocol>
   </system.webServer>
  </configuration>

使用 * 作为 Access-Control-Allow-Origin 标头的值，这表明任何域上运行的 JavaScript 都可以访问应用程序的数据。

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

使用 * 作为 Access-Control-Allow-Origin 标头的值，这表明任何域上运行的 JavaScript 都可以访问应用程序的数据。

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

  <?php
    header('Access-Control-Allow-Origin: *');
  ?>

将 * 作为 Access-Control-Allow-Origin 头文件的值表明，该应用程序的数据可供在任何域上运行的 JavaScript 访问。

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。若不采取同源策略，恶意网站便可以使用客户端凭证来运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

response.addHeader("Access-Control-Allow-Origin", "*")

将 * 用作 Access-Control-Allow-Origin 头文件的值表明该应用程序的数据可供在任何域上运行的 JavaScript 访问。

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

  Response.AddHeader "Access-Control-Allow-Origin", "*"

将 * 作为 Access-Control-Allow-Origin 头文件的值表明，该应用程序的数据可供在任何域上运行的 JavaScript 访问。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

这段代码使用 CL_ABAP_RANDOM->INT31 函数为它生成的收据页面生成“唯一”的标识符。由于 CL_ABAP_RANDOM 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

这段代码使用 Random.Next() 函数为它生成的收据页面生成“唯一”的标识符。由于 Random.Next() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能产生可预测数值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它就很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则可能会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

这段代码使用 lrand48() 函数为它生成的收据页面生成“唯一”的标识符。由于 lrand48() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器，就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。


电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

这段代码使用 Rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 Rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机性数据源，会产生 Insecure Randomness 错误。

计算机是一种具有确定性的机器，因此无法产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性。但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例：以下代码使用统计学的 PRNG 来创建 RSA 密钥。

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

该代码使用 rand.New() 函数生成 RSA 密钥的随机性。由于 rand.New() 是统计学的 PRNG，攻击者很容易猜到其生成的值。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机性数据源，会产生 Insecure Randomness 错误。

计算机是一种具有确定性的机器，因此无法产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例：以下 Spring Boot 配置文件使用统计学的 PRNG 创建安全敏感令牌。

my.secret=${random.value}

这段代码使用 Random.next() 函数为它所生成的收据页面生成独特的标识符。由于 Random.next() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

这段代码使用 Math.random() 函数为它生成的收据页面生成“唯一”的标识符。由于 Math.random() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机性数据源，会产生 Insecure Randomness 错误。

计算机是一种具有确定性的机器，因此无法产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例：下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

这段代码使用 Random.nextInt() 函数为它所生成的收据页面生成独特的标识符。由于 Random.nextInt() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

这段代码使用 rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能产生可预测数值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它就很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则可能会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

这段代码使用 DBMS_RANDOM.SEED() 函数为它生成的收据页面生成“唯一”的标识符。由于 DBMS_RANDOM.SEED() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器，就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

这段代码使用 rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

这段代码使用 Kernel.rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 Kernel.rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机性数据源，会产生 Insecure Randomness 错误。

计算机是一种具有确定性的机器，因此无法产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它就很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则可能会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例：以下代码使用统计学的 PRNG 创建用作重置密码令牌的随机值。

    sqlite3_randomness(10, &reset_token)

在对安全性要求较高的环境中，使用能够生成可预测值的函数作为随机数据源，会产生 Insecure Randomness 错误。

电脑是一种具有确定性的机器，因此不可能产生真正的随机性。伪随机数生成器 (PRNG) 近似于随机算法，始于一个能计算后续数值的种子。

PRNG 包括两种类型：统计学的 PRNG 和密码学的 PRNG。统计学的 PRNG 提供很多有用的统计属性，但其输出结果很容易预测，因此容易复制数值流。在安全性所依赖的生成值不可预测的情况下，这种类型并不适用。密码学的 PRNG 生成的输出结果较难预测，可解决这一问题。为保证值的加密安全性，必须使攻击者根本无法、或几乎不可能鉴别生成的随机值和真正的随机值。通常情况下，如果并未声明 PRNG 算法带有加密保护，那么它很可能就是统计学的 PRNG，因此不应在对安全性要求较高的环境中使用，否则会导致严重的漏洞（如易于猜测的密码、可预测的加密密钥、Session Hijacking 和 DNS Spoofing）。

示例： 下面的代码可利用统计学的 PRNG 为购买产品后仍在有效期内的收据创建一个 URL。

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

这段代码使用 Rnd() 函数为它生成的收据页面生成“唯一”的标识符。由于 Rnd() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。

可生成随机或伪随机值的传递了种子的函数不应使用常量参数进行调用。如果伪随机数值生成器（如 CL_ABAP_RANDOM 类或其变体）使用特定常数值作为种子，则通过 GET_NEXT、INT 和通过可返回或分配值的类似方法返回的值对可以收集大量 PRNG 输出的攻击者来说是可预测的。

示例 1：在以下摘录的代码中，可以通过对象 random_gen1 来预测对象 random_gen2 生成的值。

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

在此示例中，伪随机数值生成器：random_gen1 和 random_gen2 设置了相同的种子，因此 var1 = var2

可生成随机或伪随机值的传递了种子的函数不应使用常量参数进行调用。如果伪随机数值生成器（如 rand()）使用特定值作为种子（使用类似 srand(unsigned int) 的函数），则通过 rand() 和通过可返回或分配值的类似方法返回的值对可以收集一定数量 PRNG 输出的攻击者来说是可预测的。

示例 1：伪随机数生成器生成的值在前两个块中是可预测的，因为这两个块以同一种子开始。

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

在此例子中，randomNum1 和 randomNum2 的结果设置相同的种子，因此在为伪随机数值生成器 srand(2223333) 设置种子的调用后，对 rand() 的每次调用都将会以相同的调用顺序产生相同的输出。例如，输出可能与以下内容相似：

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

这些结果并不是随机的。

可生成随机或伪随机值的传递了种子的函数不应使用常量参数进行调用。如果伪随机数值生成器 (PRNG) 使用特定值作为种子（使用诸如 math.Rand.New(Source) 的函数），则通过 math.Rand.Int() 和通过可返回或分配值的类似方法返回的值对可以收集大量 PRNG 输出的攻击者来说是可预测的。

示例 1：伪随机数生成器生成的值在前两个块中是可预测的，因为这两个块以同一种子开始。

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

在此示例中，PRNG 设置了相同的种子，因此在为伪随机数值生成器 (randomGen.Seed(12345)) 设置种子的调用之后，每次调用 nextInt() 都会产生相同的输出和顺序。

可生成随机或伪随机值的传递了种子的函数不应使用常量参数进行调用。如果伪随机数值生成器（如 Random）使用特定值作为种子（使用诸如 Random.setSeed() 的函数），则通过 Random.nextInt() 和通过可返回或分配值的类似方法返回的值对可以收集大量 PRNG 输出的攻击者来说是可预测的。

示例 1：可以通过 Random 对象 randomGen1 来预测 Random 对象 randomGen2 生成的值。

        Random randomGen1 = new Random();
        randomGen1.setSeed(12345);
        int randomInt1 = randomGen1.nextInt();
        byte[] bytes1 = new byte[4];
        randomGen1.nextBytes(bytes1);

        Random randomGen2 = new Random();
        randomGen2.setSeed(12345);
        int randomInt2 = randomGen2.nextInt();
        byte[] bytes2 = new byte[4];
        randomGen2.nextBytes(bytes2);

在此示例中，伪随机数值生成器：randomGen1 和 randomGen2 设置了相同的种子，因此 randomInt1 == randomInt2，且数组 bytes1[] 和 bytes2[] 的相应值是相等的。

可生成随机或伪随机值的传递了种子的函数不应使用常量参数进行调用。如果伪随机数值生成器（如 Random）使用特定值作为种子（使用诸如 Random(Int) 的函数），则通过 Random.nextInt() 和通过可返回或分配值的类似方法返回的值对可以收集大量 PRNG 输出的攻击者来说是可预测的。

示例 1：可以通过 Random 对象 randomGen1 来预测 Random 对象 randomGen2 生成的值。

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

在此示例中，伪随机数值生成器：randomGen1 和 randomGen2 设置了相同的种子，因此 randomInt1 == randomInt2，且数组 byteArray1 和 byteArray2 的相应值是相等的。

可生成伪随机值的传递种子的函数不应使用常量整数参数进行调用。如果伪随机数生成器使用特定值作为种子，则返回的值可预测。

示例 1：伪随机数生成器生成的值在前两个块中是可预测的，因为这两个块以同一种子开始。

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

在此示例中，PRNG 设置了相同的种子，因此，在为伪随机数生成器 (random.seed(123456)) 设置种子的调用后，对 randint() 的每次调用都将会导致按相同的顺序显示相同的输出。例如，输出可能与以下内容相似：

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

这些结果并不是随机的。

类 CL_ABAP_RANDOM（或其变体）不应使用受污染参数进行初始化。这样做可使攻击者控制作为伪随机数值生成器种子的值，因此能够预测由调用方法产生的值的顺序，这些方法包括但不限于： GET_NEXT, INT, FLOAT, PACKED.

对于生成了传递了种子（如 rand()）的随机或伪随机值（如 srand()）的函数，不应该使用受污染的参数进行调用。这样做可使攻击者控制作为伪随机数值生成器种子的值，因此能够预测由调用随机数值生成器产生的值（通常为整数）的顺序。

可生成伪随机数值的函数（如 ed25519.NewKeyFromSeed()）不应使用受污染参数进行调用。这样做可使攻击者控制作为伪随机数值生成器种子的值，然后可以预测由调用伪随机数值生成器产生的值的顺序。

Random.setSeed() 不应使用受污染的整数参数进行调用。这样做可使攻击者控制作为伪随机数值生成器种子的值，因此能够预测由调用 Random.nextInt()、Random.nextShort()、Random.nextLong() 产生的、或 Random.nextBoolean() 返回的、或在 Random.nextBytes(byte[]) 中设置的值（通常为整数）的顺序。

Random.setSeed() 不应使用受污染的整数参数进行调用。这样做可使攻击者控制作为伪随机数值生成器种子的值，因此能够预测由调用 Random.nextInt()、Random.nextLong()、Random.nextDouble() 产生的、或 Random.nextBoolean() 返回的、或在 Random.nextBytes(ByteArray) 中设置的值（通常为整数）的顺序。

可生成伪随机值的函数（如 random.randint()）；不应使用受污染参数进行调用。否则攻击者可以控制用作伪随机数生成器种子的值，从而能够预测由伪随机数生成器调用产生的值（通常为整数）的顺序。

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在移动环境中，设备要利用 WiFi 连接来频繁连接不安全的公共无线网络。在这些情况下，应使用加密（安全）协议。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）发送数据。

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

由于传入的 HttpResponse 对象 res 通过未加密和未经验证的通道传输，因而可能受到危害。

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临中间人攻击，设备要利用 WiFi 连接来频繁连接不安全的公共无线网络。

示例 1：以下代码使用了不安全的 HTTP 协议（而不是 HTTPS 协议）。

    var account = new CloudStorageAccount(storageCredentials, false);

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在移动环境中，设备要利用 WiFi 连接来频繁连接不安全的公共无线网络。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）读取数据。

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

由于传入的响应 response 通过未加密和未经验证的通道传输，因而可能受到危害。

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在设备频繁连接不安全的公共无线网络的环境中。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）设置 Web 服务器。

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在移动环境中，设备要利用 WiFi 连接来频繁连接不安全的公共无线网络。

示例 1：以下 Spring Boot 配置文件禁用 TLS 协议，因此使用 HTTP 协议。

server.ssl.enabled=false

示例 2：以下 Spring 配置文件需要使用 HTTP 协议。

      <intercept-url pattern="/member/**"  access="ROLE_USER" requires-channel="http"/>

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在移动环境中，设备要利用 WiFi 连接来频繁连接不安全的公共无线网络。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）读取数据。

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

由于传入的 http.IncomingMessage 对象 res 通过未加密和未经验证的通道传输，因而可能存在安全隐患。

所有数据均通过 HTTP 以明文形式发送，容易受到攻击。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）发送数据。

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险，特别是在设备频繁连接不安全的公共无线网络的环境中。

示例 1：以下示例禁用了套接字上的加密。

...
stream_socket_enable_crypto($fp, false);
...

使用不安全、未加密或纯文本协议发送的所有通信可能会面临风险。

所有基于 HTTP、FTP 或 gopher 的通信均未经过验证和加密。因此可能面临风险。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）读取数据。

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

由于来源流 in 通过未加密和未验证的通道传输，因而可能受到危害。

所有数据均通过 HTTP 以明文形式发送，容易受到攻击。

示例 1：以下示例通过 HTTP 协议（而不是 HTTPS 协议）发送数据。

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

通过设计 JSONP 可允许执行跨域请求，但是它缺乏限制和验证请求源的机制。恶意站点可以轻松地以用户的名义执行 JSONP 请求并处理 JSON 响应。因此，强烈建议在发送 PII 或敏感数据时避免使用此通信技术。
JSONP 在设计上是自我攻击的 XSS 攻击，因为回调函数名需要被反射到请求站点以正确进行 JSON 处理。强制验证和检查回调函数名以避免 JavaScript 注入攻击。为了检查回调函数名，请考虑在可能的情况下建立允许列表或将字符限制为仅包含字母数字。