sprintf()
、FormatMessageW()
或 syslog()
。snprintf()
将一个命令行参数复制到缓冲区中。
int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}
%x
)来读取堆栈中的内容,然后函数会作为即将格式化的参数使用。(在本例中,函数没有采用任何即将格式化的参数。)通过使用 %n
格式化指令,攻击者能够对堆栈进行写入,进而使 snprintf()
记下迄今为止输出的字节数,并将其传送给指定的参数(而不是直接从参数中读取数值,这是程序员最初设计的行为)。对于这种攻击,更为的复杂的形式是使用四条交错的写入来完全控制堆栈中某个指针的值。
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
中所述。syslog()
函数有时候可以这样使用:
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
的第二个参数是格式字符串,因此 cmdBuf
中的任何格式化指令都会按照Example 1
中所述进行解释。syslog()
的正确使用方式:
...
syslog(LOG_ERR, "%s", cmdBuf);
...
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
)来读取堆栈中的内容,然后函数会作为即将格式化的参数使用。(在本例中,函数没有采用任何即将格式化的参数。)
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
中所述。syslog()
函数有时候可以这样使用:
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
的第二个参数是格式字符串,因此 cmdBuf
中的任何格式化指令都会按照Example 1
中所述进行解释。syslog()
的正确使用方式:示例 4:Apple 核心类提供了利用 format string 漏洞的有趣途径。
...
syslog(LOG_ERR, "%s", cmdBuf);
...
String.stringByAppendingFormat()
函数有时候可以这样使用:
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:[MyClass
formatInput:inputControl.text]];
...
stringByAppendingFormat()
的正确使用方式:
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
strncpy()
),使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设,是导致大多数 buffer overflow 漏洞产生的根源。
void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
strncpy()
),使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设,是导致大多数 buffer overflow 漏洞产生的根源。%d
格式说明符将一个浮点转换为 f
。
void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", f);
...
}
script
标签。
<script src="http://www.example.com/js/fancyWidget.js"></script>
www.example.com
以外的网站中,则该站点将依赖 www.example.com
来运行正确的非恶意代码。如果攻击者可以入侵 www.example.com
,则他们可以篡改 fancyWidget.js
的内容,损害站点安全。例如,他们可以将代码添加到 fancyWidget.js
中,窃取用户的机密数据。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
...
...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...
HttpResponse
对象 res
通过未加密和未经验证的通道传输,因而可能受到危害。
var account = new CloudStorageAccount(storageCredentials, false);
...
String url = 'http://10.0.2.2:11005/v1/key';
Response response = await get(url, headers: headers);
...
response
通过未加密和未经验证的通道传输,因而可能受到危害。
helloHandler := func(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "Hello, world!\n")
}
http.HandleFunc("/hello", helloHandler)
log.Fatal(http.ListenAndServe(":8080", nil))
URL url = new URL("http://www.android.com/");
HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
try {
InputStream in = new BufferedInputStream(urlConnection.getInputStream());
readStream(in);
...
}
instream
通过未加密和未验证的通道传输,因而可能受到危害。
var http = require('http');
...
http.request(options, function(res){
...
});
...
http.IncomingMessage
对象 res
通过未加密和未经验证的通道传输,因而可能存在安全隐患。
NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];
...
stream_socket_enable_crypto($fp, false);
...
require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...
in
通过未加密和未验证的通道传输,因而可能受到危害。
val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))
responseFuture
通过未加密和未经验证的通道传输,因而可能受到危害。
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)
Config.PreferServerCipherSuites
字段控制服务器是使用客户端还是服务器的首选密码套件。如果所选密码套件存在已知缺陷,则使用客户端首选密码套件可能会引入安全漏洞。PreferServerCipherSuites
字段设置为 false
。
conf := &tls.Config{
PreferServerCipherSuites: false,
}
client = SSHClient()
algorithms_to_disable = { "ciphers": untrusted_user_input }
client.connect(host, port, "user", "password", disabled_algorithms=algorithms_to_disable)
SSHClient.connect(...)
使用较弱的算法 3DES-CBC。
...
Using(SqlConnection DBconn = new SqlConnection("Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;"))
{
...
}
...
...
insecure_config = {
'user': username,
'password': retrievedPassword,
'host': databaseHost,
'port': "3306",
'ssl_disabled': True
}
mysql.connector.connect(**insecure_config)
...
NSURLSession
、NSURLConnection
或 CFURL
时默认启用 App Transport Security (ATS),强制应用程序使用 HTTPS
和 TLS 1.2
开展与后端服务器的所有网络通信。Info.plist
中的以下条目将完全禁用 App Transport Security:示例 2:应用程序
<key>NSAppTransportSecurity</key>
<dict>
<!--Include to allow all connections (DANGER)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
Info.plist
中的以下条目将为 yourserver.com
禁用 App Transport Security:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>yourserver.com</key>
<dict>
<!--Include to allow subdomains-->
<key>NSIncludesSubdomains</key>
<true/>
<!--Allow plain HTTP requests-->
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
<!--Downgrades TLS version-->
<key>NSTemporaryExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
</dict>
<a href="http://www.example.com/index.html"/>
www.example.com
来加载自己的网页。
...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...
None
。使用不安全的通道凭据设置发送的数据不受信任。root_certificates
参数的值将被设置为 None
,private_key
参数的值将被设置为 None
,certificate_chain
参数的值将被设置为 None
。
...
channel_creds = grpc.ssl_channel_credentials()
...
...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...
None
或 False
。通过具有不安全的服务器凭据设置的服务器发送和接收的数据不受信任。
...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...
HSTS
) 标头,但未能将此保护应用于子域,从而使攻击者能够通过执行 HTTPS Stripping 攻击从子域连接窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头所指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 连接。
<http auto-config="true">
...
<headers>
...
<hsts include-sub-domains="false" />
</headers>
</http>
HSTS
) 头文件,但未能将此保护应用于子域,从而使攻击者能够通过执行 HTTPS stripping 攻击从子域连接窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。HSTS
) 标头。这样会让攻击者能够用普通 HTTP 连接替换 SSL/TLS 连接,并通过执行 HTTPS Stripping 攻击来窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头所指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 连接。
<http auto-config="true">
...
<headers>
...
<hsts disabled="true" />
</headers>
</http>
HSTS
) 标头,这使得攻击者能够将 SSL/TLS 连接替换为普通 HTTP 连接,并通过执行 HTTPS Stripping 攻击来窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。HSTS
) 头文件,这使得攻击者能够通过执行 HTTPS stripping 攻击使用普通 HTTP 连接替换 SSL/TLS 连接并窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。modp2
组初始化 Diffie-Hellman 密钥交换协议(该协议使用 1024 位素数):
const dh = getDiffieHellman('modp2');
dh.generateKeys();
...
HSTS
) 标头。这样会让攻击者能够用普通 HTTP 连接替换 HTTPS 连接,并通过执行 HTTPS Stripping 攻击来窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头所指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 连接。
@Override
protected void configure(HttpSecurity http) throws Exception {
http.httpStrictTransportSecurity().maxAgeInSeconds(300);
}
HSTS
) 头文件,这使得攻击者能够通过执行 HTTPS stripping 攻击使用普通 HTTP 连接替换 HTTPS 连接并窃取敏感信息。HSTS
) 是一种安全标头,它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://
,通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。SmtpClient
的配置不正确,未使用 SSL/TLS 与 SMTP 服务器进行通信:
string to = "bob@acme.com";
string from = "alice@acme.com";
MailMessage message = new MailMessage(from, to);
message.Subject = "SMTP client.";
message.Body = @"You can send an email message from an application very easily.";
SmtpClient client = new SmtpClient("smtp.acme.com");
client.UseDefaultCredentials = true;
client.Send(message);
<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="host" value="smtp.acme.com" />
<property name="port" value="25" />
<property name="javaMailProperties">
<props>
<prop key="mail.smtp.auth">true</prop>
</props>
</property>
</bean>
session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)