var yamlString = getYAMLFromUser();
// Setup the input
var input = new StringReader(yamlString);
// Load the stream
var yaml = new YamlStream();
yaml.Load(input);
var yaml = require('js-yaml');
var untrusted_yaml = getYAMLFromUser();
yaml.load(untrusted_yaml)
import yaml
yamlString = getYamlFromUser()
yaml.load(yamlString)
範例 2：下列 ASPX 程式碼可讓 ASP.NET 框架 Script 的要求自動重新導向至 Microsoft Ajax CDN：
...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...
...
<asp:ScriptManager
ID="ScriptManager1"
EnableCdn="true"
Runat="Server" />
...
Example 2 中，ScriptManager 控制可配置其 ASPX 頁面，以便自動重新導向所有指令碼要求至適當的 CDN。=cmd|'/C calc.exe'!Z0。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源，則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
public void Service()
{
string name = HttpContext.Request["name"];
string data = GenerateCSVFor(name);
HttpContext.Response.Clear();
HttpContext.Response.Buffer = true;
HttpContext.Response.AddHeader("content-disposition", "attachment;filename=file.csv");
HttpContext.Response.Charset = "";
HttpContext.Response.ContentType = "application/csv";
HttpContext.Response.Output.Write(tainted);
HttpContext.Response.Flush();
HttpContext.Response.End();
}
=cmd|'/C calc.exe'!Z0。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源，則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
foo := r.FormValue("foo")
...
w := csv.NewWriter(file)
w.Write(foo)
}
=cmd|'/C calc.exe'!Z0。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源，則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
@RequestMapping(value = "/api/service.csv")
public ResponseEntity<String> service(@RequestParam("name") String name) {
HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");
String data = generateCSVFor(name);
return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
}
=cmd|'/C calc.exe'!Z0。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源，則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
@RequestMapping(value = "/api/service.csv")
fun service(@RequestParam("name") name: String): ResponseEntity<String> {
val responseHeaders = HttpHeaders()
responseHeaders.add("Content-Type", "application/csv; charset=utf-8")
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv")
val data: String = generateCSVFor(name)
return ResponseEntity(data, responseHeaders, HttpStatus.OK)
}
services
.AddGraphQLServer()
.AddQueryType<Query>()
.AddMutationType<Mutation>();
app.use('/graphql', graphqlHTTP({
schema
}));
app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
'graphql',
schema = schema
))
Metadata 物件，這可能允許攻擊者控制關鍵通訊協定欄位。Metadata 類別通常用於存放 Google 遠端程序呼叫 (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 遠端程序呼叫 (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);
...
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 Redirect 攻擊無招架能力，所以透過使用者輸入設定 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 Redirect 攻擊無招架能力，所以透過使用者輸入設定 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 版本無法使用新行字元設定表頭，您的應用程式可能就可以抵擋 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 Redirect 攻擊無招架能力，所以透過使用者輸入設定 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 Redirect 攻擊無招架能力，所以透過使用者輸入設定 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 平台。跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 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 Redirect 攻擊無招架能力，所以透過使用者輸入設定 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
...
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
hidden 類型的 <input> 標籤表示使用隱藏欄位。
<input type="hidden">
X-XSS-Protection 標頭。設定標頭值為 false (0) 時，會停用 Cross-Site Scripting 保護。X-XSS-Protection 標頭已明確停用，這可能會增加 Cross-Site Scripting 攻擊的風險。X-XSS-Protection 標頭。設定標頭值為 false (0) 時，會停用 Cross-Site Scripting 保護。
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection 表頭已明確停用，這可能會增加 Cross-site scripting 攻擊的風險。X-XSS-Protection 標頭。設定標頭值為 false (0) 時，會停用 Cross-Site Scripting 保護。X-XSS-Protection 表頭已明確停用，這可能會增加 Cross-site scripting 攻擊的風險。X-XSS-Protection 標頭。設定標頭值為 false (0) 時，會停用 Cross-Site Scripting 保護。Application_BeginRequest 為空，或不包括將 X-Content-Type-Options 設定為 nosniff 的函數呼叫，或嘗試移除該表頭。X-Content-Type-Options: nosniff。X-Content-Type-Options 設定為 nosniff。X-Content-Type-Options: nosniff 用於可能含有使用者可控制內容的每個頁面中。net.http.DetectContentType() 確定資源 Content-Type：
...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
content_type := DetectContentType(body)
...
X-Content-Type-Options 設定為 nosniff，或明確停用此安全性標頭。X-Content-Type-Options: nosniff。
<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
X-Content-Type-Options 設定為 nosniff，或明確停用此安全性標頭。X-Content-Type-Options: nosniff。X-Content-Type-Options 設為 nosniff，或明確停用此安全性表頭。X-Content-Type-Options: nosniff。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
Response.AppendHeader("Access-Control-Allow-Origin", "*");
* 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
* 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
<?php
header('Access-Control-Allow-Origin: *');
?>
* 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
response.addHeader("Access-Control-Allow-Origin", "*")
* 作為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可供在任何網域上執行的 JavaScript 存取。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
* 作為 Access-Control-Allow-Origin 標頭的值，表示應用程式的資料可供在任何網域上執行的 JavaScript 存取。Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。
Response.AddHeader "Access-Control-Allow-Origin", "*"
* 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。
...
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 以便取得其帳戶的進一步資訊。
<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<http-method> 標籤中未明確定義如 HEAD 的動詞，因此可透過以 HEAD 要求替代 GET 或 POST 要求，來執行管理功能。為了能讓 HEAD 要求執行管理功能，條件 3 必須適用 - 應用程式必須依據 POST 以外的動詞執行指令。某些網路/應用程式伺服器會接受任意的非標準 HTTP 動詞，並以具有指定 GET 要求的型態回應。若情況為此，攻擊者將可使用要求中的任意動詞，來檢視管理頁面。
GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com
FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com
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)，那就會安全很多。
string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}
Random.Next() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.Next() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
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，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器，那就會安全很多。
<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>
Rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)
rand.New() 函數為 RSA 金鑰產生隨機性。由於 rand.New() 是統計式 PRNG，所以攻擊者很容易就能猜到其所產生的值。
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}
Random.nextInt() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.nextInt() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}
Math.random() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Math.random() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}
Random.nextInt() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.nextInt() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密型 PRNG)，那就會安全很多。
function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}
rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
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，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器，那就會安全很多。
def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL
rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}
Kernel.rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Kernel.rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。
def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}
Random.nextInt() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.nextInt() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
sqlite3_randomness(10, &reset_token)
...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...
Rnd() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Rnd() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。
...
private bool CertificateCheck(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
...
return true;
}
...
HttpWebRequest webRequest = (HttpWebRequest) WebRequest.Create("https://www.myTrustedSite.com");
webRequest.ServerCertificateValidationCallback = CertificateCheck;
WebResponse response = webRequest.GetResponse();
...
...
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_callback);
...
...
config := &tls.Config{
// Set InsecureSkipVerify to skip the default validation
InsecureSkipVerify: true,
...
}
conn, err := tls.Dial("tcp", "example.com:443", conf)
..
...
Email email = new SimpleEmail();
email.setHostName("smtp.servermail.com");
email.setSmtpPort(465);
email.setAuthenticator(new DefaultAuthenticator(username, password));
email.setSSLOnConnect(true);
email.setFrom("user@gmail.com");
email.setSubject("TestMail");
email.setMsg("This is a test mail ... :-)");
email.addTo("foo@bar.com");
email.send();
...
smtp.mailserver.com:465 時，會立即接受核發給「hackedserver.com」的憑證。現在，此應用程式可能會在有漏洞的 SSL 連線上將使用者敏感資訊洩漏給被駭客入侵的伺服器。
...
var options = {
key : fs.readFileSync('my-server-key.pem'),
cert : fs.readFileSync('server-cert.pem'),
requestCert: true,
...
}
https.createServer(options);
...
https.Server 物件時，requestCert 設定被指定為 true，但未設定 rejectUnauthorized，進而預設為 false。這表示，雖然伺服器的建立是為了透過 SSL 驗證用戶端，但是即使憑證未使用所提供之 CA 的清單進行授權，依然會接受連線。
var tls = require('tls');
...
tls.connect({
host: 'https://www.hackersite.com',
port: '443',
...
rejectUnauthorized: false,
...
});
rejectUnauthorized 已設定為 false，所以表示將接受未經授權的憑證，並且仍會與無法識別的伺服器建立連線。現在，此應用程式可能會在有漏洞的 SSL 連線上將使用者敏感資訊洩漏給被駭客入侵的伺服器。NSURLConnectionDelegate 配置為接受任何 HTTPS 憑證：
implementation NSURLRequest (IgnoreSSL)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
@end
Example 1 的 NSURLRequest 連線到以 SSL 保護的伺服器時，如果所要求的伺服器憑證是自行簽署的憑證 (並因而不會驗證)，那麼將不會產生任何警告或錯誤。因此，應用程式現在可能會透過有漏洞的 SSL 連線洩漏敏感的使用者資訊。
...
import ssl
ssl_sock = ssl.wrap_socket(s)
...
require 'openssl'
...
ctx = OpenSSL::SSL::SSLContext.new
ctx.verify_mode=OpenSSL::SSL::VERIFY_NONE
...
NSURLConnectionDelegate 配置為接受任何 HTTPS 憑證：
class Delegate: NSObject, NSURLConnectionDelegate {
...
func connection(connection: NSURLConnection, canAuthenticateAgainstProtectionSpace protectionSpace: NSURLProtectionSpace?) -> Bool {
return protectionSpace?.authenticationMethod == NSURLAuthenticationMethodServerTrust
}
func connection(connection: NSURLConnection, willSendRequestForAuthenticationChallenge challenge: NSURLAuthenticationChallenge) {
challenge.sender?.useCredential(NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!), forAuthenticationChallenge: challenge)
challenge.sender?.continueWithoutCredentialForAuthenticationChallenge(challenge)
}
}
Example 1 的 NSURLConnectionDelegate 連線到以 SSL 保護的伺服器時，如果所要求的伺服器憑證是自行簽署的憑證 (並因而不會驗證)，那麼將不會產生任何警告或錯誤。因此，應用程式現在可能會透過有漏洞的 SSL 連線洩漏敏感的使用者資訊。NSURLSession 類別中，SSL/TLS 鏈結驗證將由應用程式的驗證委派方法來處理，使用此方法時，應用程式不會提供憑證來向伺服器驗證使用者 (或應用程式)，而是檢查伺服器在 SSL/TLS 交握期間提供的驗證，然後告知 URL 載入系統應接受還是拒絕這些憑證。以下程式碼顯示 proposedCredential 剛剛將所收到的挑戰之 NSURLSessionDelgate 傳回作為階段作業的憑證，以有效地避開伺服器驗證：
class MySessionDelegate : NSObject, NSURLSessionDelegate {
...
func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
...
completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, challenge.proposedCredential)
...
}
...
}
...
FINAL(client) = cl_apc_tcp_client_manager=>create(
i_host = ip_adress
i_port = port
i_frame = VALUE apc_tcp_frame(
frame_type =
if_apc_tcp_frame_types=>co_frame_type_terminator
terminator =
terminator )
i_event_handler = event_handler ).
...
client 物件與遠端伺服器之間的通訊很容易遭受入侵，因為它透過未加密和未經驗證的通道傳輸。
...
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)
...
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)
...
...
using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions {
Credentials = ChannelCredentials.Insecure
});
...
...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...
None。使用不安全的通道認證所傳送的資料，都不能信任。root_certificates 參數的值將設為 None，private_key 參數的值將設為 None，以及 certificate_chain 參數的值將設為 None。
...
channel_creds = grpc.ssl_channel_credentials()
...
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 = @「您可以非常輕鬆地從應用程式傳送電子郵件訊息。」；
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)