网站扫描出的漏洞解决：检测到目标Content-Security-Policy、X-XSS-Protection/Content-Security-Policy响应头缺失、加密算法等处理修复方法_检测到目标content-security-policy响应头缺失

​​​​    使用一些漏洞扫描工具对服务器进行搜查，总得扫出一些漏洞，比如检测到目标X-...响应头缺失之类的，扫描后报了不少头漏洞问题，之前碰到过也进行了一些修复，主要是在nginx的配置中添加一些配置， 这次又遇到一些，在这里统一整理了一下这次碰到的漏洞问题及解决办法：

漏洞1：检测到目标Content-Security-Policy响应头缺失

Content Security Policy (CSP) 通过告诉浏览器一系列规则，严格规定页面中哪些资源允许有哪些来源， 不在指定范围内的统统拒绝，可以服务器添加 Content-Security-Policy 头信息来指定规则解决。 upgrade-insecure-requests;connect-src *会使安全进行升级，即一个http页面中所有调用的静态资源会自动升级使用https调用。但这样也会产生很多问题，如果调用的资源实际并不支持https的话，这时如果不是线上环境可以不理会，线上环境使用https就没有这样的问题了。在测试环境中可以不加这个配置。

# 如下的配置会将http资源升级成调用https资源
add_header Content-Security-Policy “upgrade-insecure-requests;connect-src *”;
# 建议使用如下配置
add_header Content-Security-Policy "default-src 'self' localhost:8080 'unsafe-inline' 'unsafe-eval' blob: data: ;";
add_header Content-Security-Policy "default-src *;style-src 'self' 'unsafe-inline';script-src 'self' 'unsafe-inline' 'unsafe-eval';img-src * data:;worker-src * blob:;font-src 'self' data:;";

漏洞2：检测到目标X-XSS-Protection响应头缺失

# 增加header处理
add_header X-XSS-Protection "1";

漏洞3： 检测到目标X-XSS-Protection响应头缺失

HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击(XSS)时，浏览器将停止加载页面。X-XSS-Protection响应头的缺失使得目标URL更易遭受跨站脚本攻击。
add_header X-Xss-header  "1;mode=block";

漏洞4： 检测到目标Content-Security-Policy响应头缺失

​​​​​​​add_header X-Frame-Options SAMEORIGIN;

漏洞5： 检测到目标URL存在客户端（JavaScript）Cookie引用

应该是检测到一些URL中存在cookie中的值，多是比如页面跳转的时候携带的token数据之类，如果是这种可以忽略。

漏洞6： 检测到目标源码中可能存在用户名或者密码信息泄露

这是在你的数据发送的，比如post账户的时候发现有使用username/password这种很明显的账号密码字段数值，不过这种调整意义也不大。

漏洞7： 检测到目标服务器可能存在系统路径信息泄露

    参考其提示是在VUE的js文件里提到的VUE工程中一些类似路径的字符，不过这些都不是目标服务器上的路径，可以忽略。 

    因为原有一个业务服务使用Nginx做了一个代理，漏洞扫描后报了不少头信息问题，进行了修复并将方法进行记录如下，以下配置均在nginx.conf文件中添加。

漏洞8： 点击劫持：缺少X-Frame-Options

关于http头部 X-Frame-Options 缺失漏洞解决，X-Frame-Options有三个可选项：
DENY #拒绝任何域加载
SAMEORIGIN #允许同源域下加载（常用）
ALLOW-FROM #可以定义允许frame加载的页面地址
解决方法：add_header X-Frame-Options SAMEORIGIN;

漏洞9： HTTP Strict-Transport-Security 响应头缺失

HTTP Strict-Transport-Security 可以限定浏览器只能通过HTTPS访问当前资源，禁止HTTP方式。
解决方法：add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

漏洞10： HTTP Referrer-Policy 响应头缺失

    referer是用来防止CORS（跨站请求伪造）的一种最常见及有效的方式。而Referrer-Policy则是客户端对这个带信息策略的配置。推荐使用strict-origin-when-cross-origin作为默认策略。
Referrer-Policy可以设置的值有如下列表：

no-referrer 整个Referer首部会被移除。访问来源信息不随着请求一起发送
no-referrer-when-downgrade 没有指定策略时的默认行为。在同等安全级别的情况下，引用页面的地址会被发送(HTTPS->HTTPS)，但是在降级的情况下不会被发送 (HTTPS->HTTP)。
origin 在任何情况下，仅发送文件的源作为引用地址。
origin-when-cross-origin 对于同源的请求，会发送完整的URL作为引用地址，但是对于非同源请求仅发送文件的源。
same-origin 对于同源的请求会发送引用地址，但是对于非同源请求则不发送引用地址信息
strict-origin 在同等安全级别的情况下，发送文件的源作为引用地址(HTTPS->HTTPS)，但是在降级的情况下不会发送 (HTTPS->HTTP)。
strict-origin-when-cross-origin 对于同源的请求，会发送完整的URL作为引用地址；在同等安全级别的情况下，发送文件的源作为引用地址(HTTPS->HTTPS)；在降级的情况下不发送此首部 (HTTPS->HTTP)。
unsafe-url 无论是同源请求还是非同源请求，都发送完整的 URL（移除参数信息之后）作为引用地址。（最不安全）

解决方法：add_header Referrer-Policy strict-origin-when-cross-origin;

漏洞11： HTTP X-Permitted-Cross-Domain-Policies 响应头缺失

X-Permitted-Cross-Domain-Policies
    用于指定当不能将crossdomain.xml文件（当需要从别的域名中的某个文件中读取 Flash 内容时用于进行必要设置的策略文件）放置在网站根目录等场合时采取的替代策略。
常用的配置值：master-only 只允许使用主策略文件（/crossdomain.xml）
解决方法：add_header X-Permitted-Cross-Domain-Policies master-only;

漏洞12： HTTP X-Download-Options 响应头缺失

    Web 服务器对于 HTTP 请求的响应头中缺少 X-Download-Options会导致浏览器提供的安全特性失效，容易遭受 Web 前端黑客攻击的影响。可以使用X-Download-Options标头下载所请求的数据。 X-Download Options标头可在Internet Explorer 8及更高版本的浏览器中使用。这个标头就像一个深度防御机制，特别适合于允许用户上传内容的应用程序，避免用户直接打开其上传的包含恶意代码的文件，通过向X-Download-Options HTTP头添加noopen指令来删除用户必须打开文件的选项。
解决方法：add_header X-Download-Options noopen

漏洞13： HTTP X-Content-Type-Options 响应头缺失

    互联网上的资源有各种类型，通常浏览器会根据响应头的Content-Type字段来分辨它们的类型。例如："text/html"代表html文档，"image/png"是PNG图片，"text/css"是CSS样式文档。然而，有些资源的Content-Type是错的或者未定义。这时，某些浏览器会启用MIME-sniffing来猜测该资源的类型，解析内容并执行。这个响应头的值只能是nosniff，可用于IE8+和Chrome。
解决方法：add_header X-Content-Type-Options nosniff 

漏洞14：中危险漏洞：目标主机SSH服务存在RC4、CBC或None弱加密算法：Bad SSH2 cipher spec

    第三方检测服务器时发现有漏洞：中危险漏洞：目标主机SSH服务存在RC4、CBC或None弱加密算法的解决，提供的弱加密算法列表如下：

Weak encryption algorithms:
aes128-cbc
aes192-cbc
aes256-cbc
blowfish-cbc
cast128-cbc
3des-cbc

    于是编辑 /etc/ssh/sshd_config，在后面把上面的这些内容列表都加入增加行内容示例如下：
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes25-cbc

    但在编辑完配置文件后使用sshd -t检查配置时报错：

/etc/ssh/sshd_config line 118: Bad SSH2 cipher spec 'aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes25-cbc'.Bad SSH2 cipher spec

    报错是因为这些列表中存在当前sshd服务不支持的cipher，使用命令：ssh -Q cipher查看支持的cipher列表,然后将列表中的内容排除掉漏洞中的弱加密列表，写入sshd_config再保存检测。如果是Bad SSH2 mac spec则是当前列表中存在不支持的mac。使用命令：ssh -Q mac查看支持的mac，然后同样处理。

    最后整理得如下内容，把它编辑写入文件/etc/ssh/sshd_config最后一行，使用sshd -t检查通过，使用service sshd start重启成功。下面表示支持这些加密算法：不要有上面这些列表即可。
Ciphers aes128-ctr,aes192-ctr,aes256-ctr