三级等保及安全测试相关问题总结

大家好，我是“Java分布式架构实战”Jamesfu。今天给大家介绍一些三级等保及安全测试相关问题总结的内容，希望能给大家带来一些思考。

问题背景

最近我经历了几次代码审计、安全测试、三级等保等项目，发现系统可能存在以下应用程序级问题，在此总结一下，供大家参考学习。

1. 存在4个低危漏洞。
2. 密码不具备有效期限制，未设置固定期限内强制用户修改密码。
3. 系统未对常见密码进行限制，可以使用常见弱密码如 abcd1234 作为密码。
4. 退出后会话令牌未失效，仍可继续使用其执行请求。
5. 应用程序未限制有效并发会话数量，同一帐号可在多个浏览器中同时登录。
6. 登录缺少双因素认证
7. 存在越权访问，一个管理级别的功能，比如给角色分配权限，可以被低级别用户通过在浏览器中记住的网页地址访问
8. 三员管理，三权分立，指系统管理员、安全保密管理员、安全审计员
9. redis应设置密码访问
10. es就设置密码访问或限制特定服务器访问(整改建议：1.elasticsearch设置口令；2.配置文件绑定host地址，禁止任意IP访问elasticsearch服务。)
11. 关闭swagger-ui或设计口令
12. 关闭SpringBootAcurator或设置口令
13. 关闭Druid数据库连续池或设置口令
14. Supervisor未授权访问，关闭访问或设置口令
15. 异地实时数据及日志备份
16. 密码、手机号、邮箱等重要信息就加密&加盐处理，防止被泄漏或恶意篡改
17. SQL注入攻击
18. 其他
    • 提供安全设计方案及评审和修订记录
    • 配置管理： 应记录和保存基本配置信息，包括网络拓扑结构、各个设备安装的软件组件、软件组件的版本和补丁信息、各个设备或软件组件的配置参数等
    • 备份与恢复管理：应规定备份信息的备份方式、备份频度、存储介质、保存期等；
    • 补充变更记录表

本次重点分享在一次安全测评中发现的4个低危安全漏洞。

4个低危安全漏洞。

1. “Content-Security-Policy”头缺失

描述：可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件

位置。可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息。CSP

值缺失或不当会导致 Web 应用程序容易受到 XSS、点击劫持等的攻击。

风险等级：低

风险数值：5.0

风险分析：未配置 Content-Security-Policy 头。

1. “X-Content-Type-Options”头设置缺失

描述：“X-Content-Type-Options”头（具有“nosniff”值）防止 IE 和 Chrome 忽略响应的内

容类型。此操作可能防止不可信内容（例如，用户上载内容）在用户浏览器上执行（例如，

在恶意命名之后）。

风险等级：低

风险数值：5.0

风险分析：未配置 X-Content-Type-Options 头。

1. “X-XSS-Protection”头缺失

描述：值为‘1’的“X-XSS-Protection”报头强制跨站点脚本编制过滤器进入启用模式，即使

用户已禁用。此过滤器内置于最新版本的 Web 浏览器（IE 8 +、Chrome 4+）中，在缺省情况

下通常为已启用状态。虽然此过滤器不是第一个也不是唯一一个针对跨站点脚本编制的防御

程序，但它可以作为额外保护层。

风险等级：低

风险数值：5.0

风险分析：未配置 X-XSS-Protection 头。 Version:0.9 StartHTML:0000000105 EndHTML:0000004667 StartFragment:0000000141 EndFragment:0000004627

1. 缺少 SameSite 属性的 Cookie

描述：该属性可以有三个值：“Lax”、“Strict”或“None”。如果使用“None”，Web 站点可能

会向另一个 Web 站点创建跨域 POST HTTP 请求，浏览器会自动向该请求添加 Cookie。如

果没有适当的保护措施（例如反 CSRF 令牌），则可能会导致跨站请求伪造 (CSRF) 攻击。

建议将属性设置为“Strict”。

风险等级：低

风险数值：5.0

风险分析：在 Cookies 中未配置 Samesite 属性。

经过对相关安全头研究，决定使用以下配置来解决，供大家参考：

### 在server节点下增加以下配置
add_header Content-Security-Policy "default-src * blob: data:;style-src 'self' 'unsafe-inline' *; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: data: *.amap.com *.qq.com *.baidu.com *.gtimg.com;"; 
add_header X-Content-Type-Options nosniff; 
add_header X-XSS-Protection "1; mode=block"; 
proxy_cookie_path / "/; httponly; secure; SameSite=Strict";
复制代码

相关内容介绍

server_tokens

该响应头用于禁止 nginx 在响应中报文中包含版本信息。因为具体的版本可能会存在未知 bug。

server_tokens off;

X-Frame-Options 同源策略

该响应头用于是否允许浏览器加载 frame、 iframe、 object 等属性。可以使用该功能来避免 点击劫持

add_header X-Frame-Options SAMEORIGIN;
该指令用三个可用的配置

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM example.com/\ 当设置为 DENY 时，站点禁止任何页面被嵌入。

当设置为 SAMEORIGIN 时，只允许加载同源的 fram/iframe/object。

当设置为 ALLOW-FROM 时，只允许加载指定的源。

Content-Security-Policy CSP防护

该响应头主要用于规定页面可以加载那些资源（css/js/img 等）。看一个简单的配置

定义所有资源文件的默认加载规则为self，表示允许
相同来源的内容（相同的协议、域名和端口）
add_header Content-Security-Policy "default-src 'self';"; 或 add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';font-src 'self' data:; img-src 'self' data: 'unsafe-inline' https:; style-src 'self' 'unsafe-inline';frame-ancestors 'self'; frame-src 'self';connect-src https:";

X-XSS-Protection 开启XSS防护

add_header X-XSS-Protection "1; mode=block";
该响应头是用于防范及过滤 XSS 的。可用的几个指令如下：

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=
说明

0，禁用 XSS 过滤
1，开启 XSS 过滤
1; mode=block，开启 XSS 过滤，并且若检查到 XSS 攻击，停止渲染页面。
X-XSS-Protection: 1; report=，开启 XSS 过滤，并且若检查到 XSS 攻击，将使用指导的 url 来发送报告。

X-Content-Type-Options资源解析

在我们通常的请求响应中，浏览器会根据 HTTP 响应的 Content-Type 来分辨响应的类型。如 text/html 代表 html 文档。 但当响应类型未指定或错误指定时，浏览会尝试启用 MIME-sniffing 来猜测资源的响应类型。

如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的 HTML 和 JavaScript 代码。由于未关闭资源的类型猜测，浏览器将直接执行嵌入的 JavaScript 代码，而不是显示图片。

add_header X-Content-Type-Options nosniff;
用来指定浏览器对未指定或错误指定 Content-Type 资源真正类型的猜测行为，nosniff 表示不允许任何猜测。（Jerry Qu）

这个响应头的值只能是 nosniff，可用于 IE8+ 和 Chrome。

Strict-Transport-Security HSTS防护

Strict-Transport-Security，简称 HSTS。该响应头用于标识浏览器用 HTTPS 替代 HTTP 的方式去访问目标站点。

我们知道 HTTPS 相对于 HTTP 有更好的安全性，而很多 HTTPS 网站，也可以通过 HTTP 来访问。开发人员的失误或者用户主动输入地址，都有可能导致用户以 HTTP 访问网站，降低了安全性。一般，我们会通过 Web Server 发送 301/302 重定向来解决这个问题。 （Jerry Qu）

我们可以使用下面方式启用 HSTH。

add_header strict-transport-security "max-age=16070400; includeSubDomains;";

当用户第一次访问后，将返回一个包含了 strict-transport-security 响应头的字段。他将告诉浏览器，在接下来的 16070400 秒内，当前网站的所有请求都强制使用 HTTPS 的方式访问。即使用户手动输入 http://，浏览器也会强制使用 HTTPS 方式访问。

参数 includeSubDomains 是可选的，当指定了该参数，所有子域名将采用同样的 HSTS 规则。

可以看到 HSTS 可以很好的解决 HTTPS 降级攻击，但是对于 HSTS 生效前的首次 HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了 HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用 HTTPS 协议。 （Jerry Qu）

Facebook配置示例

strict-transport-security: max-age=60
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:*;
复制代码

参考资料

• Nginx配置各种响应头防止XSS,点击劫持,frame恶意攻击
• Nginx 配置之安全篇
• Content-Security-Policy的实战应用
• 前端安全配置之Content-Security-Policy(csp)
• 三员管理，三权分立
• 常见的Web攻击手段，拿捏了！
• 常见的Web攻击方式有哪些？黑客：28种够不够？总有一款适合你
• 常见的Web攻击和防御总结
• 常见六大Web安全攻防解析