当满足以下任一条件时，就会发生 File Permission Manipulation 错误：

1.攻击者可能会指定操作中所用的路径，以修改文件系统上的权限。

2.攻击者可能会指定文件系统上的操作所分配的权限。

示例 1：以下代码使用系统环境变量中的输入设置文件权限。如果攻击者可更改系统环境变量，则他们可能会使用该程序获得程序所处理文件的访问权限。如果程序依然易受 Path Manipulation 的攻击，那么攻击者可能会利用这一漏洞来访问系统中的任意文件。

    permissions := strconv.Atoi(os.Getenv("filePermissions"));
    fMode := os.FileMode(permissions)
    os.chmod(filePath, fMode);
    ...

当满足以下任一条件时，就会产生 file permission manipulation 错误：

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例：以下代码旨在为用户设置适当的文件权限以通过 FTP 上载网页。它使用来自 HTTP 请求的输入将文件标记为外部用户可查看的文件。

	$rName = $_GET['publicReport'];
	chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...

但是，如果攻击者为 publicReport 提供恶意值（例如，../../localuser/public_html/.htpasswd），那么应用程序将允许攻击者读取指定文件。

示例 2：以下代码使用来自配置文件的输入来设置默认权限掩码。如果攻击者可以篡改配置文件，则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击，那么攻击者可能会利用这一漏洞访问系统中的任意文件。

...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...

当满足以下任一条件时，就会产生 File Permission Manipulation 错误：

1. 攻击者能够指定在文件系统上修改权限的操作所使用的路径。

2. 攻击者能够指定文件系统上的操作所分配的权限。

示例 1： 以下代码使用系统环境变量中的输入设置文件权限。 如果攻击者可更改系统环境变量，则他们可能使用该程序获得程序所处理文件的访问权限。 如果程序还容易受 Path Manipulation 攻击，那么攻击者可能会利用这一漏洞访问系统中的任意文件。

    permissions = os.getenv("filePermissions");
    os.chmod(filePath, permissions);
    ...

当满足以下任一条件时，就会产生 file permission manipulation 错误：

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例：以下代码旨在为用户设置适当的文件权限以通过 FTP 上载网页。它使用来自 HTTP 请求的输入将文件标记为外部用户可查看的文件。

...
  rName = req['publicReport']
  File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...

但是，如果攻击者为 publicReport 提供恶意值（例如，../../localuser/public_html/.htpasswd），那么应用程序将允许攻击者读取指定文件。

示例 2：以下代码使用来自配置文件的输入来设置默认权限掩码。如果攻击者可以篡改配置文件，则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击，那么攻击者可能会利用这一漏洞访问系统中的任意文件。

...
mask = config_params['perms']
File.chmod(filename, mask)
...

HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

示例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.aspx?name=alice&name=hacker

示例 2：下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

    ...
    String lang = Request.Form["lang"];
    WebClient client = new WebClient();
    client.BaseAddress = url;
    NameValueCollection myQueryStringCollection = new NameValueCollection();
    myQueryStringCollection.Add("q", lang);
    client.QueryString = myQueryStringCollection;
    Stream data = client.OpenRead(url);
    ...

URL: http://www.host.com/election.aspx?poll_id=4567
链接 1：<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">英语<a>
链接 2：<a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">西班牙语<a>

程序员尚未考虑下面这种可能性：攻击者可能会提供一个 lang（例如 en&poll_id=1），然后攻击者可以随意更改该 poll_id。

HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据
它可能从最后一个参数中提取数据
它可能从所有参数中提取数据并把它们连接起来


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

例 2：下列代码使用来自于 HTTP 请求的输入来呈现两个超链接。

    <%
        ...
        $id = $_GET["id"];
        header("Location: http://www.host.com/election.php?poll_id=" . $id);
        ...
    %>

URL： http://www.host.com/election.php?poll_id=4567
链接 1： <a href="vote.php?poll_id=4567&candidate=white">White 先生的投票<a>
链接 2： <a href="vote.php?poll_id=4567&candidate=green">Green 女士的投票<a>

程序员没有考虑到攻击者可能提供 poll_id（例如“4567&candidate=green”）的可能性，届时得到的页面中将包含以下注入链接，因此，Green 女士将始终投票选择捡出第一个参数的应用程序服务器。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">White 先生的投票<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Green 女士的投票<a>

HTTP Parameter Pollution (HPP) 攻击包含将编码的查询字符串分隔符注入其他现有的参数中。如果 Web 应用程序没有正确地检查用户输入，恶意用户可能会破坏应用程序的逻辑，进行客户端侧或服务器侧攻击。如果再向 Web 应用程序提交参数，并且如果这些参数与现有参数的名称相同，则 Web 应用程序可能会有下列一种反应：

它可能只从第一个参数中提取数据。
它可能从最后一个参数中提取数据。
它可能从所有参数中提取数据并把它们连接起来。


例如：
- ASP.NET/IIS 使用所有情况下出现的参数
- Apache Tomcat 仅使用第一次出现的参数并忽略其他参数
- mod_perl/Apache 将值转换为值数组

例 1：根据应用程序服务器和应用程序自身的逻辑，下列请求可能造成与身份验证系统的混淆，使攻击者能模拟别的用户。
http://www.server.com/login.php?name=alice&name=hacker

因为这表明，攻击者已经指定了 name=alice，但他们添加了额外的 name=alice&，如果在提取第一个匹配项的服务器上使用它，那么它可能会模仿 alice 以便获取有关她的帐户的详细信息。

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

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

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

   val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
   val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))

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

所有数据均通过 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)

应用程序通过未加密通道与其数据库服务器通信，可能为该应用程序的公司和用户带来重大安全风险。在这种情况下，攻击者可以修改用户输入的数据，甚至可以对数据库服务器执行任意 SQL 命令。

示例 1：以下代码会导致应用程序通过未加密通道与其数据库服务器通信：

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

使用未指定的 Google Remote Procedure Call (gRPC) 通道凭据设置会导致安全设置被设置为不安全的默认值 None。使用不安全的通道凭据设置发送的数据不受信任。

示例 1：以下代码显示了使用所有默认参数创建的 gRPC 通道凭据对象，该对象会导致所有通道凭据安全设置都设置为不安全的默认值。在这种情况下，root_certificates 参数的值将被设置为 None，private_key 参数的值将被设置为 None，certificate_chain 参数的值将被设置为 None。

...
channel_creds = grpc.ssl_channel_credentials()
...

使用未指定的 Google Remote Procedure Call (gRPC) 服务器凭据设置会导致安全设置被设置为不安全的默认值 None 或 False。通过具有不安全的服务器凭据设置的服务器发送和接收的数据不受信任。

示例 1：以下代码显示了使用默认参数创建的 gRPC 服务器凭据对象，此对象会导致客户端身份验证被禁用。

...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...

HTTPS stripping 攻击是一种中间人攻击，攻击者可在所有 HTTP 流量中监视引用 HTTPS 的位置标头和链接，并使用 HTTP 版本予以替换。攻击者保留所有 HTTP 替换版本的列表，以使 HTTPS 请求返回到服务器。所有断开的 HTTP 连接通过 HTTPS 代理连接到了服务器。受害者和攻击者之间的所有流量均通过 HTTP 发送，从而暴露了用户名、密码和其他私人信息，但服务器仍然从攻击者接收预期的 HTTPS 流量，因此一切看似正常。

HTTP 严格传输安全 (HSTS) 是一种安全标头，它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://，通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。

HTTPS stripping 攻击是一种中间人攻击，攻击者可在所有 HTTP 流量中监视引用 HTTPS 的位置标头和链接，并使用 HTTP 版本予以替换。攻击者保留所有 HTTP 替换版本的列表，以使 HTTPS 请求返回到服务器。所有断开的 HTTP 连接通过 HTTPS 代理连接到了服务器。受害者和攻击者之间的所有流量均通过 HTTP 发送，从而暴露了用户名、密码和其他私人信息，但服务器仍然从攻击者接收预期的 HTTPS 流量，因此一切看似正常。

HTTP 严格传输安全 (HSTS) 是一种安全标头，它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://，通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。

HTTPS stripping 攻击是一种中间人攻击，攻击者可在所有 HTTP 流量中监视引用 HTTPS 的位置标头和链接，并使用 HTTP 版本予以替换。攻击者保留所有 HTTP 替换版本的列表，以使 HTTPS 请求返回到服务器。所有断开的 HTTP 连接通过 HTTPS 代理连接到了服务器。受害者和攻击者之间的所有流量均通过 HTTP 发送，从而暴露了用户名、密码和其他私人信息，但服务器仍然从攻击者接收预期的 HTTPS 流量，因此一切看似正常。

HTTP 严格传输安全 (HSTS) 是一种安全标头，它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://，通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。

HTTPS stripping 攻击是一种中间人攻击，攻击者可在所有 HTTP 流量中监视引用 HTTPS 的位置标头和链接，并使用 HTTP 版本予以替换。攻击者保留所有 HTTP 替换版本的列表，以使 HTTPS 请求返回到服务器。所有断开的 HTTP 连接通过 HTTPS 代理连接到了服务器。受害者和攻击者之间的所有流量均通过 HTTP 发送，从而暴露了用户名、密码和其他私人信息，但服务器仍然从攻击者接收预期的 HTTPS 流量，因此一切看似正常。

HTTP 严格传输安全 (HSTS) 是一种安全标头，它指示浏览器在标头自身指定的期间始终连接到通过 SSL/TLS 返回 HSTS 标头的站点。即使用户在浏览器 URL 栏中输入了 http://，通过 HTTP 到服务器的连接还是将自动替换为 HTTPS 版本。

通过未加密网络发送的敏感数据容易被任何可拦截网络通信的攻击者读取/修改。

示例 1：以下 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);

通过未加密网络发送的敏感数据容易被任何可拦截网络通信的攻击者读取/修改。

示例 1：以下 SMTP 客户端的配置不正确，未使用 SSL/TLS 与 SMTP 服务器进行通信：

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件可能容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

对于依赖 SSL/TLS 来确保数据传输的真实性、机密性和完整性的应用程序，如果未能选择足够强大的加密算法，则可能容易受到攻击。保护机制强度由身份验证、加密和散列算法决定，统称为密码套件。密码套件用于通过 TLS/SSL 通道传输敏感信息。

当服务器支持一系列不同强度的密码套件时，使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制并窃取或修改敏感信息。攻击者可以操纵部署在配置不安全的 Web 服务器上的应用程序来选择弱密码套件。弱密码套件容易受到强力攻击和中间人攻击，这可能导致敏感数据被拦截和操纵。

传输层安全 (TLS) 协议和安全套接字层 (SSL) 协议提供了一种保护机制，可以确保在客户端和 Web 服务器之间所传输数据的真实性、保密性和完整性。TLS 和 SSL 都进行了多次修订，因此需要定期进行版本更新。每次新的修订都旨在解决以往版本中发现的安全漏洞。使用不安全版本的 TLS/SSL 会削弱数据保护力度，并可能允许攻击者危害、窃取或修改敏感信息。

弱版本的 TLS/SSL 可能会呈现出以下一个或多个属性：

- 没有针对中间人攻击的保护
- 身份验证和加密使用相同密钥
- 消息身份验证控制较弱
- 没有针对 TCP 连接关闭的保护
- 使用弱密码套件

这些属性的存在可能会允许攻击者截取、修改或篡改敏感数据。