输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括：“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。
apex:iframe 源 URL 可能会导致恶意内容载入 Visualforce 页面中。iframe URL。Salesforce.com 是可信赖的，受害者将信任该页面并提供所有请求的信息。iframesrc URL 参数直接用作 apex:iframe 目标 URL。
<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>
iframesrc 参数被设置为指向恶意网站，那么该框架将使用恶意网站的内容进行呈现。
<iframe src="http://evildomain.com/">
Metadata 对象，这可能会允许攻击者控制关键协议字段。Metadata 类通常用于存放 Google Remote Procedure Call (gRPC) 使用的基本协议的标头数据。当基本协议为 HTTP 时，控制 Metadata 对象中的数据会使系统容易受到 HTTP Header Manipulation 的攻击。也可能会导致其他攻击向量，且这些攻击向量主要基于基本协议。Metadata 对象的输入的不可信数据。
...
String? evnVar = System.Environment.GetEnvironmentVariable("evnVar ");
Metadata headers = new Metadata();
headers.Add("field", evnVar);
CallOptions callOptions = new CallOptions(headers);
...
Metadata 对象，这可能会允许攻击者控制关键协议字段。Metadata 类通常用于存放 Google Remote Procedure Call (gRPC) 使用的基本协议的标头数据。当基本协议为 HTTP 时，控制 Metadata 对象中的数据会使系统容易受到 HTTP Header Manipulation 的攻击。也可能会导致其他攻击向量，且这些攻击向量主要基于基本协议。Metadata 对象的输入的用户可控数据。
...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
NameNode、DataNode、JobTraker 等 Hadoop 群集核心组件用来更改群集的状态。Job，其输入来自 Hadoop 群集中主计算机的命令行：
public static void run(String args[]) throws IOException {
String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();
/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
Job 在有害环境中可能被篡改。JobConf 值。Job，其输入来自 Hadoop 群集中主计算机的命令行：例 2：以下代码显示了攻击者通过命令行参数控制运行作业中止的情形：
public void run(String args[]) throws IOException {
String inputDir = args[0];
String outputDir = args[1];
// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);
Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);
return job;
}
public static void main(String[] args) throws Exception {
JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();
}
let template = Handlebars.compile('{{foo}}', { noEscape: true })
Prototype Pollution 漏洞的攻击。__defineGetter__ 函数。
let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author 和 Jane Smith 组成，则包含此标头的 HTTP 响应可能会采用以下形式：
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 和 bar，然后 HTTP 响应将被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader() 方法时将其转换为 %0d、%0a 和 %00。如果您正在使用的最新的 .NET 框架不允许使用新行字符设置头文件，则应用程序便不会容易受到 HTTP Response Splitting 攻击。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
Author.Text 的值不包含任何 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
...
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。name 和 value 可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头：
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author 和 Jane Smith 组成，则包含此标头的 HTTP 响应可能会以这样的形式出现：
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 和 bar，于是该 HTTP 响应将会拆分为如下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header() 函数时，最新版本的 PHP 将生成一个警告并停止创建头文件。如果您的 PHP 版本能够阻止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。
<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>
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
...
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
location = req.field('some_location')
...
response.addHeader("location",location)
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author 的名字，并在发往站点另一部分的 Get 请求中使用它。
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交的是一个恶意字符串，例如“Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...”，那么 HTTP 响应就会被分割成以下形式的两个响应：
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。name 和 value 可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头：
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author 和 Jane Smith 组成，则包含此标头的 HTTP 响应可能会以这样的形式出现：
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 和 bar，于是该 HTTP 响应将会拆分为如下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 cookie 头文件中。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
Example 1 以适应 Android 平台。Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 TCP 连接的另一用户发出的。这种攻击可以通过以下方式实现：攻击者诱骗用户，让他们自己提交恶意请求；或在远程情况下，攻击者与用户共享同一个连接到服务器（如共享代理服务器）的 TCP 连接。最理想的情况是，攻击者通过这种方式使用户相信自己的应用程序已经遭受了黑客攻击，进而对应用程序的安全性失去信心。最糟糕的情况是，攻击者可能提供经特殊技术处理的内容，这些内容旨在模仿应用程序的执行方式，但会重定向用户的私人信息（如帐号和密码），将这些信息发送给攻击者。
...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
location = req.field('some_location')
...
response.addHeader("location",location)
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
...
IllegalArgumentException。 如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。 然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
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
...
CC 或 BCC），从而利用这些标头向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。CC 标头匿名注入垃圾邮件，因为电子邮件是从受害者服务器发送的。
func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}
...
subject: [Contact us query] Page not working
...
subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 标头将采用以下形式：
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC 或 BCC），从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。CC 标题匿名注入垃圾邮件，因为电子邮件会从受害者服务器进行发送。
String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);
...
subject: [Contact us query] Page not working
...
subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 头将表现为以下形式：
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC 或 BCC），从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。CC 标题。
$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);
...
subject: [Contact us query] Page not working
...
subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 头将表现为以下形式：
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC 或 BCC），从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。CC 标题。
body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)
...
subject: [Contact us query] Page not working
...
subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 头将表现为以下形式：
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
X-XSS-Protection 标头。将标头值设置为 false (0) 后，禁用 Cross-Site Scripting 保护功能。X-XSS-Protection 标头。X-XSS-Protection 标头。将标头值设置为 false (0) 后，禁用 Cross-Site Scripting 保护功能。
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection 标头。X-XSS-Protection 标头。将标头值设置为 false (0) 后，禁用 Cross-Site Scripting 保护功能。X-XSS-Protection 标头。X-XSS-Protection 标头。将标头值设置为 false (0) 后，禁用 Cross-Site Scripting 保护功能。required 属性，可指定是否必须填写某一输入表单字段。指定字段类型可确保根据输入类型对输入进行检查。甚至还可以使用自定义 pattern 属性根据正则表达式来对输入进行检查。然而，在表单标签上添加 novalidate 属性以及在提交输入标签上添加 formnovalidate 属性时，将禁用这一验证功能。novalidate 属性禁用表单验证。例 2：以下示例通过
<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
formnovalidate 属性禁用表单验证。
<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>
...
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);
...
lang（例如 en&poll_id=1），然后攻击者可以随意更改该 poll_id。
...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...
lang（例如 en&poll_id=1），然后攻击者将可以随意更改该 poll_id。
<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>
name=alice，但他们添加了额外的 name=alice&，如果在提取第一个匹配项的服务器上使用它，那么它可能会模仿 alice 以便获取有关她的帐户的详细信息。rawmemchr() 时使用不受信任的命令行参数作为搜索缓冲区。
int main(int argc, char** argv) {
char* ret = rawmemchr(argv[0], 'x');
printf("%s\n", ret);
}
argv[0] 的一个子字符串，但是程序最终可能会输出位于 argv[0] 之前的部分内存。elements 构建 HTML sanitizer 策略：
...
String elements = prop.getProperty("AllowedElements");
...
public static final PolicyFactory POLICY_DEFINITION = new HtmlPolicyBuilder()
.allowElements(elements)
.toFactory();
....
elements 而使 HTML sanitizer 策略接受这些元素。
nresp = packet_get_int();
if (nresp > 0) {
response = xmalloc(nresp*sizeof(char*));
for (i = 0; i < nresp; i++)
response[i] = packet_get_string(NULL);
}
nresp 拥有值 1073741824，sizeof(char*) 拥有典型值 4，那么 nresp*sizeof(char*) 的操作结果将溢出，xmalloc() 参数将变为 0。大多数 malloc() 实施将允许分配 0 字节缓冲区，导致随后的循环迭代次数超出堆缓冲区 response。
char* processNext(char* strm) {
char buf[512];
short len = *(short*) strm;
strm += sizeof(len);
if (len <= 512) {
memcpy(buf, strm, len);
process(buf);
return strm + len;
} else {
return -1;
}
}
512，输入将不会被处理。问题是 len 为一个带符号的整数，因此针对最大结构长度的检查是用带符号的整数完成的，但是针对 memcpy() 调用，len 会转化为一个不带符号的整数。如果 len 为负，那么结构将看起来有一个适当的尺寸（将执行 if 分支），但是通过 memcpy() 复制的内存数量将相当大，攻击者将能够使用 strm 中的数据溢出堆栈。
77 accept-in PIC 9(10).
77 num PIC X(4) COMP-5. *> native 32-bit unsigned integer
77 mem-size PIC X(4) COMP-5.
...
ACCEPT accept-in
MOVE accept-in TO num
MULTIPLY 4 BY num GIVING mem-size
CALL "CBL_ALLOC_MEM" USING
mem-pointer
BY VALUE mem-size
BY VALUE 0
RETURNING status-code
END-CALL
num 拥有值 1073741824，则操作 MULTIPLY 4 BY num 的结果会溢出，并且参数 mem-size 到 malloc() 将是 0。大多数 malloc() 实现允许分配 0 字节的缓冲区，这会导致堆缓冲区 mem-pointer 在后续语句中溢出。
String arg = request.getParameter("arg");
...
Intent intent = new Intent();
...
intent.setClassName(arg);
ctx.startActivity(intent);
...
Intent 启动活动、启动服务或传递广播，可使攻击者能够任意启动内部应用程序组件、控制内部组件的行为，或通过临时授权间接访问内容提供者提供的受保护数据。Intent 的 Extra 捆绑包中嵌套的任意 Intent。Intent，通过调用 startActivity、startService 或 sendBroadcast 来启动组件。Intent，并使用该 Intent 启动活动。
...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...
username 和 password 序列化为位于 C:\user_info.json 的 JSON 文件：
...
StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);
using (JsonWriter writer = new JsonTextWriter(sw))
{
writer.Formatting = Formatting.Indented;
writer.WriteStartObject();
writer.WritePropertyName("role");
writer.WriteRawValue("\"default\"");
writer.WritePropertyName("username");
writer.WriteRawValue("\"" + username + "\"");
writer.WritePropertyName("password");
writer.WriteRawValue("\"" + password + "\"");
writer.WriteEndObject();
}
File.WriteAllText(@"C:\user_info.json", sb.ToString());
JsonWriter.WriteRawValue() 来执行，将不会对 username 和 password 中的不可信赖数据进行验证以转义与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，可能会更改已序列化的 JSON 的结构。在本例中，在设置 username 的值的提示符下输入用户名时，如果非特权用户 mallory（密码为 Evil123!）将 ","role":"admin 附加到其用户名中，则最终保存到 C:\user_info.json 的 JSON 将为：
{
"role":"default",
"username":"mallory",
"role":"admin",
"password":"Evil123!"
}
Dictionary 对象，其中 JsonConvert.DeserializeObject() 如下所示：
String jsonString = File.ReadAllText(@"C:\user_info.json");
Dictionary<string, string> userInfo = JsonConvert.DeserializeObject<Dictionary<string, strin>>(jsonString);
Dictionary 对象中 username、password 和 role 密钥的最终值将分别为 mallory、Evil123! 和 admin。在没有进一步验证反序列化 JSON 值是否有效的情况下，应用程序会错误地为用户分配 mallory“管理员”特权。username 和 password 序列化为位于 ~/user_info.json 的 JSON 文件：
...
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
username := r.FormValue("username")
password := r.FormValue("password")
...
jsonString := `{
"username":"` + username + `",
"role":"default"
"password":"` + password + `",
}`
...
f, err := os.Create("~/user_info.json")
defer f.Close()
jsonEncoder := json.NewEncoder(f)
jsonEncoder.Encode(jsonString)
}
username 和 password 中的不可信赖数据进行验证以转义与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，这可能会更改已序列化的 JSON 结构。在本例中，如果非特权用户 mallory（密码为 Evil123!）在输入其用户名时附加了 ","role":"admin，则最终保存到 ~/user_info.json 的 JSON 将为：
{
"username":"mallory",
"role":"default",
"password":"Evil123!",
"role":"admin"
}
mallory“管理员”特权。username 和 password 序列化为位于 ~/user_info.json 的 JSON 文件：
...
JsonFactory jfactory = new JsonFactory();
JsonGenerator jGenerator = jfactory.createJsonGenerator(new File("~/user_info.json"), JsonEncoding.UTF8);
jGenerator.writeStartObject();
jGenerator.writeFieldName("username");
jGenerator.writeRawValue("\"" + username + "\"");
jGenerator.writeFieldName("password");
jGenerator.writeRawValue("\"" + password + "\"");
jGenerator.writeFieldName("role");
jGenerator.writeRawValue("\"default\"");
jGenerator.writeEndObject();
jGenerator.close();
JsonGenerator.writeRawValue() 来执行，将不会对 username 和 password 中的不可信赖数据进行验证以转义与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，可能会更改已序列化的 JSON 的结构。在本例中，在设置 username 的值的提示符下输入用户名时，如果非特权用户 mallory（密码为 Evil123!）将 ","role":"admin 附加到其用户名中，则最终保存到 ~/user_info.json 的 JSON 将为：
{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}
HashMap 对象，其中 Jackson 的 JsonParser 如下所示：
JsonParser jParser = jfactory.createJsonParser(new File("~/user_info.json"));
while (jParser.nextToken() != JsonToken.END_OBJECT) {
String fieldname = jParser.getCurrentName();
if ("username".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}
if ("password".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}
if ("role".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}
if (userInfo.size() == 3)
break;
}
jParser.close();
HashMap 对象中 username、password 和 role 密钥的最终值将分别为 mallory、Evil123! 和 admin。在没有进一步验证反序列化 JSON 值是否有效的情况下，应用程序会错误地为用户分配 mallory“管理员”特权。
var str = document.URL;
var url_check = str.indexOf('name=');
var name = null;
if (url_check > -1) {
name = decodeURIComponent(str.substring((url_check+5), str.length));
}
$(document).ready(function(){
if (name !== null){
var obj = jQuery.parseJSON('{"role": "user", "name" : "' + name + '"}');
...
}
...
});
name 中的不可信数据进行验证，以避免与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，可能会更改已序列化的 JSON 的结构。在此示例中，如果非特权用户 mallory 将 ","role":"admin 附加到 URL 中的名称参数，JSON 将变成：
{
"role":"user",
"username":"mallory",
"role":"admin"
}
jQuery.parseJSON() 解析，并设置为普通对象，这意味着 obj.role 将立即返回 "admin" 而不是 "user"_usernameField 和 _passwordField 序列化为 JSON。
...
NSString * const jsonString = [NSString stringWithFormat: @"{\"username\":\"%@\",\"password\":\"%@\",\"role\":\"default\"}" _usernameField.text, _passwordField.text];
NSString.stringWithFormat: 来执行，将不会对 _usernameField 和 _passwordField 中的不可信赖数据进行验证以转义与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，可能会更改已序列化的 JSON 的结构。在本例中，如果非特权用户 mallory（密码为 Evil123!）在将 ","role":"admin 输入 _usernameField 字段时将其附加到其用户名中，则最终 JSON 将为：
{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}
NSDictionary 对象，其中 NSJSONSerialization.JSONObjectWithData: 如下所示：
NSError *error;
NSDictionary *jsonData = [NSJSONSerialization JSONObjectWithData:[jsonString dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:&error];
NSDictionary 对象中 username、password 和 role 的最终值将分别为 mallory、Evil123! 和 admin。在没有进一步验证反序列化 JSON 值是否有效的情况下，应用程序会错误地为用户分配 mallory“管理员”特权。
import json
import requests
from urllib.parse import urlparse
from urllib.parse import parse_qs
url = 'https://www.example.com/some_path?name=some_value'
parsed_url = urlparse(url)
untrusted_values = parse_qs(parsed_url.query)['name'][0]
with open('data.json', 'r') as json_File:
data = json.load(json_File)
data['name']= untrusted_values
with open('data.json', 'w') as json_File:
json.dump(data, json_File)
...
name 中不受信任的数据进行验证以转义与 JSON 相关的特殊字符。这使得用户可以任意插入 JSON 密钥，可能会改变序列化 JSON 的结构。在此示例中，如果非特权用户 mallory 将 ","role":"admin 附加到 URL 中的 name 参数，则 JSON 将变为：
{
"role":"user",
"username":"mallory",
"role":"admin"
}
usernameField 和 passwordField 序列化为 JSON：
...
let jsonString : String = "{\"username\":\"\(usernameField.text)\",\"password\":\"\(passwordField.text)\",\"role\":\"default\"}"
usernameField 和 passwordField 中不受信任的数据进行验证以转义与 JSON 相关的特殊字符。这样，用户就可以任意插入 JSON 密钥，可能会更改已序列化的 JSON 的结构。在本例中，如果非特权用户 mallory（密码为 Evil123!）在将 ","role":"admin 输入 usernameField 字段时将其附加到其用户名中，则最终 JSON 将为：
{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}
NSDictionary 对象，其中 NSJSONSerialization.JSONObjectWithData: 如下所示：
var error: NSError?
var jsonData : NSDictionary = NSJSONSerialization.JSONObjectWithData(jsonString.dataUsingEncoding(NSUTF8StringEncoding), options: NSJSONReadingOptions.MutableContainers, error: &error) as NSDictionary
NSDictionary 对象中 username、password 和 role 的最终值将分别为 mallory、Evil123! 和 admin。在没有进一步验证反序列化 JSON 值是否有效的情况下，应用程序会错误地为用户分配 mallory“管理员”特权。
$userInput = getUserIn();
$document = getJSONDoc();
$part = simdjson_key_value($document, $userInput);
echo json_decode($part);
userInput 是用户可控制的，恶意用户可以利用这一点来访问 JSON 文档中的任何敏感数据。
def searchUserDetails(key:String) = Action.async { implicit request =>
val user_json = getUserDataFor(user)
val value = (user_json \ key).get.as[String]
...
}
key 是可由用户控制的，恶意用户可以利用它来访问用户的密码，以及 JSON 文档中可能包含的任何其他私人数据。search 方法的 javax.naming.directory.SearchControls 实例的 returningObjectFlag 设置为 true，或使用代表其设置此标志的库函数，执行对象返回搜索。
<beans ... >
<authentication-manager>
<ldap-authentication-provider
user-search-filter="(uid={0})"
user-search-base="ou=users,dc=example,dc=org"
group-search-filter="(uniqueMember={0})"
group-search-base="ou=groups,dc=example,dc=org"
group-role-attribute="cn"
role-prefix="ROLE_">
</ldap-authentication-provider>
</authentication-manager>
</beans>