配置类安全问题学习小结
目录
一、前言
二、漏洞类型
目录
一、前言
二、漏洞类型
2.1 Strict Transport Security Not Enforced
2.2 SSL Certificate Cannot Be Trusted
2.3 SSL Anonymous Cipher Suites Supported
2.4 "Referrer Policy”Security 头值不安全
2.5 “Content-Security-Policy”头缺失
2.6 具有不安全、不正确或缺少 SameSite 属性的 Cookie
2.7 加密会话 (SSL) Cookie 中缺少 Secure 属性
2.8 发现可高速缓存的 SSL 页面
2.9 在应用程序中发现不必要的 Http 响应头（具体事件具体分析）
2.10 弱密码套件 - ROBOT 攻击: 服务器支持易受攻击的密码套件
2.11 检测到 SHA-1 密码套件
2.12 检测到弱密码: 并非所有密码套件均支持完全前向保密
2.13 过度许可的 CORS 访问测试
2.14 Cookie without HttpOnly flag set
2.15 SSH Weak Key Exchange Algorithms Enable
2.16 SSH Server CBC Mode Ciphers Enabled
2.17 X-Frame-Options Header Not Set
2.18 X-Content-Type-Options Not set
2.19 X-Xss-Protection not set
2.20 CORS (Cross-Origin Resource Sharing) origin validation failure
2.21 TLS 1.0 enabled（版本可变化）
2.23 Insecure Inline Frame (iframe)
2.24 未设置X-Permitted-Cross-Domain-Policies响应头
2.25 未设置X-Download-Options响应头
2.1 Strict Transport Security Not Enforced
2.2 SSL Certificate Cannot Be Trusted
2.3 SSL Anonymous Cipher Suites Supported
2.4 "Referrer Policy”Security 头值不安全
2.5 “Content-Security-Policy”头缺失
2.6 具有不安全、不正确或缺少 SameSite 属性的 Cookie
2.7 加密会话 (SSL) Cookie 中缺少 Secure 属性
2.8 发现可高速缓存的 SSL 页面
2.9 在应用程序中发现不必要的 Http 响应头（具体事件具体分析）
2.10 弱密码套件 - ROBOT 攻击: 服务器支持易受攻击的密码套件
2.11 检测到 SHA-1 密码套件
2.12 检测到弱密码: 并非所有密码套件均支持完全前向保密
2.13 过度许可的 CORS 访问测试
2.14 Cookie without HttpOnly flag set
2.15 SSH Weak Key Exchange Algorithms Enable
2.16 SSH Server CBC Mode Ciphers Enabled
2.17 X-Frame-Options Header Not Set
2.18 X-Content-Type-Options Not set
2.19 X-Xss-Protection not set
2.20 CORS (Cross-Origin Resource Sharing) origin validation failure
2.21 TLS 1.0 enabled（版本可变化）
2.23 Insecure Inline Frame (iframe)
一、前言
此文主要是针对扫描器常见的一些配置性漏洞的概述及如何修复的一些建议。
二、漏洞类型
2.1 Strict Transport Security Not Enforced
1、原理
"Strict Transport Security Not Enforced" 是一个安全性警告，通常出现在浏览器的开发者工具控制台中，表明网站未正确执行HTTP Strict Transport Security（HSTS）策略。HSTS是一种安全机制，用于确保用户访问网站时始终使用HTTPS连接，而不是不安全的HTTP连接。
- HTTP Strict Transport Security (HSTS) 是一个HTTP响应头，服务器可以使用它来告知浏览器在一段时间内仅使用HTTPS连接访问网站。
- 当浏览器首次访问支持HSTS的网站时，服务器会发送HSTS头，浏览器将记住这个策略并在之后的一段时间内（由max-age指定）强制使用HTTPS连接。
2、修复措施
启用HTTPS： 确保您的网站已经启用了HTTPS，即已配置有效的SSL/TLS证书，并且能够通过HTTPS访问。如果您的网站仍然在使用HTTP，请升级为HTTPS。
添加HSTS头： 在您的Web服务器配置中，确保已添加正确的HSTS头。以下是一个示例Nginx配置：
server { listen 443 ssl; server_name your_domain.com; ssl_certificate /etc/nginx/ssl/your_domain.crt; ssl_certificate_key /etc/nginx/ssl/your_domain.key; # 其他SSL配置... # 启用HSTS，并设置max-age值 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # 其他服务器配置... } #max-age 值表示HSTS策略的有效期（以秒为单位），上面的示例中是一年。 #includeSubDomains 告诉浏览器要应用HSTS策略到所有子域名。
测试HSTS策略： 使用浏览器访问您的网站，并检查开发者工具控制台中是否不再显示"Strict Transport Security Not Enforced"警告。确保浏览器已经成功记住了HSTS策略。
定期更新证书和策略： 定期更新SSL/TLS证书，并确保HSTS策略的
max-age值足够长，以保持长期有效性。PS：HSTS是一个强制性的安全策略，一旦启用，浏览器将始终要求使用HTTPS连接，如果SSL证书过期或不可用，用户可能无法访问您的网站。因此，在启用HSTS之前，请确保您的HTTPS配置正确无误
2.2 SSL Certificate Cannot Be Trusted
1、概述
"SSL Certificate Cannot Be Trusted" 表示您的浏览器或客户端在尝试建立安全连接时遇到了 SSL 证书的信任问题。这通常是由以下几个原因引起的：
证书过期： SSL 证书具有有效期限，一旦证书过期，浏览器或客户端将不信任该证书。解决方法是更新或续订证书。
自签名证书： 如果您使用自签名证书而不是由受信任的第三方证书颁发机构（CA）签发的证书，那么浏览器或客户端可能不信任它。解决方法是使用受信任的 CA 颁发的证书。
不匹配的域名： SSL 证书通常与特定的域名或子域名相关联。如果您使用证书与当前访问的域名不匹配，也会导致此问题。确保您的证书与您的域名匹配。
受信任 CA 根证书丢失或过期： 浏览器或操作系统中的受信任根证书可能已过期或丢失。您可以更新浏览器、操作系统或 CA 根证书存储以解决此问题。
2、修复措施
检查证书过期： 确保您的 SSL 证书没有过期，如果过期了，联系证书颁发机构以获得新的证书。
使用受信任的 CA 证书： 如果您使用自签名证书，考虑使用由受信任的第三方 CA 颁发的证书，以确保浏览器或客户端信任它。
验证域名匹配： 确保证书与您当前访问的域名匹配。如果不匹配，需要获取相应域名的证书。
更新受信任的 CA 根证书： 如果浏览器或操作系统中的 CA 根证书已过期或丢失，更新它们以确保正确的信任链。
2.3 SSL Anonymous Cipher Suites Supported
1、概述
"SSL Anonymous Cipher Suites Supported" 表示服务器支持匿名加密套件，这是一种不安全的配置，因为匿名加密套件不要求客户端提供身份验证，这可能会导致安全漏洞。修复此问题的方法是禁用匿名加密套件并配置更安全的加密套件。
2、修复措施
更新服务器配置： 打开服务器配置文件，通常是Web服务器（如Apache、Nginx）或TLS/SSL中间件（如OpenSSL）的配置文件。查找并禁用匿名加密套件。具体的配置选项和语法可能因服务器软件而异。
配置加密套件： 配置服务器以使用更安全的加密套件，例如支持双向身份验证的套件。确保选择的套件具有足够的安全性，并与您的安全需求相匹配。
重新启动服务器： 在更新服务器配置后，重新启动服务器以使更改生效。
#使用nmap检测支持的算法 nmap -sV -p 443 --script ssl-enum-ciphers xx.xx.xx.xx
部分配置举例
ssl_prefer_server_ciphers on;
ssl_ciphers 'HIGH:!aNULL:!eNULL:!EXPORT:!LOW:!MD5:!RC4:!3DES:!PSK:!SRP:!DSS:!CAMELLIA:!SEED';
#推荐配置：
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!3DES:!ADH:!RC4:!DH:!DHE:!IDEA:!DES;
ssl_prefer_server_ciphers on;：此指令告诉服务器优先使用服务器端的加密套件顺序，以确保客户端使用的是服务器认为更安全的套件。
ssl_ciphers：这是用于配置加密套件的地方。在上述配置中，我们使用了一系列参数和加密套件名称，以定义允许使用的加密套件。HIGH表示使用高强度的加密套件，而后面的:!aNULL:!eNULL:!EXPORT:!LOW:!MD5:!RC4:!3DES:!PSK:!SRP:!DSS:!CAMELLIA:!SEED部分是用于禁用特定的加密套件类型，包括匿名加密套件。
PS：要严格使用安全算法的话，可参考Ciphersuite Info
2.4 "Referrer Policy”Security 头值不安全
1、概述
"Referrer Policy" 是一种安全相关的HTTP头，用于控制浏览器在发送请求时，是否包含引用页面的信息（Referrer）。Referrer 是指告诉服务器请求是从哪个页面链接过来的信息。这个头的值可以设置为不同的策略，以决定是否要发送 Referrer 信息，以及要发送的信息内容。
"Referrer Policy" 头值不安全通常是指服务器的设置允许了过于广泛或不安全的 Referrer 信息传递，可能导致信息泄露、隐私问题或安全漏洞。修复这个问题的关键在于将 "Referrer Policy" 设置为更为安全的策略，以减少信息泄露的风险。
2、修复措施
常见修复措施：
- Strict-origin-when-cross-origin 策略： 这是一种相对安全的策略，它在同一站点之间发送完整的 Referrer，但在跨站点请求时仅发送 Origin 部分。这有助于保护用户隐私，但仍提供了有用的信息。
Referrer-Policy: strict-origin-when-cross-origin
- No-Referrer 策略： 这是最安全的策略，完全禁用了 Referrer 信息的传递。这可以防止信息泄露，但可能会破坏一些网站功能。
Referrer-Policy: no-referrer
- Same-origin 策略： 这个策略只在同一站点内发送 Referrer 信息，不会在跨站点请求时发送。
Referrer-Policy: same-origin
- 安全自定义策略： 您可以根据您的网站需求，自定义安全的 Referrer 策略，以平衡隐私和功能需求。
配置方式：
- Nginx配置文件中加上
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
2.5 “Content-Security-Policy”头缺失
1、概述
"Content-Security-Policy"（CSP）是一种重要的HTTP头，用于帮助防止跨站脚本攻击（XSS）和其他安全威胁。它允许您明确定义允许加载和执行的资源源点，从而减少恶意脚本的风险。当网站未配置CSP头时，可能会存在安全风险。
- CSP通过在HTTP头中定义策略，告诉浏览器只允许从特定源加载内容。这可以包括脚本、样式、图像、字体等资源。
- CSP还可以定义不允许执行内联脚本（例如，