AppScan等保问题

最新推荐文章于 2024-01-10 14:12:28 发布

Ikarosxx

最新推荐文章于 2024-01-10 14:12:28 发布

阅读量1.6k

点赞数 1

分类专栏：安全文章标签：安全

本文链接：https://blog.csdn.net/qq_29656325/article/details/126399971

版权

安全专栏收录该内容

3 篇文章 0 订阅

订阅专栏

等保

背景

最近公司有个客户需要对接等保
然后将项目给安全公司扫了一遍
给我们发来了一份文档(AppScan扫描出来的)
从此走上一周的等保之路

漏洞

发给我们的漏洞如下

SQL注入/返回格式

文档里有几类可以归为是返回格式的问题
比如sql注入、非法参数
我们系统有2个分页参数是在mybatis里是不用#{}的，所以有注入风险
为此我们写了一个过滤器防止一些参数
问题有2个

过滤器参数不完整，有些无法过滤
已经过滤了，但由于返回格式暴露了异常，安全报告上仍然显示（非法参数也是，虽然无法执行，但会暴露内部异常）

第一个问题通过完善过滤器内容
第二个需要在java后端里进行全局异常处理，即@ControllerAdvice详情见

通过全局异常处理可以解决如下

JSON 中反映的未清理用户输入
整数溢出
应用程序错误

完善过滤器解决SQL注入相关

危险文件遍历

扫描器会遍历你的接口，加上一些常见文件以及后缀，比如.log,.zip判断可不可以获取到一些文件
在我们的SpringBoot项目中，有一些写法是@PathVariable
导致了当接收类型是String时会导致这个漏洞出现
他觉得响应是200，而且返回格式是application/json，所以是漏洞
主要是发现压缩目录

解决方法:
写个过滤器禁止掉这些特定后缀的，返回404
也可以在nginx里配置也可以在SpringBoot项目配置

弱密码套件

在我们使用nginx的情况下，需要配置nginx使用的TLS版本和密码套件
需要根据实际检测报告反馈修改配置

# https用
ssl_protocols TLSv1.2;
# Enable modern TLS cipher suites
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256';

请求头相关

包含如下请求头需要处理

Strict-Transport-Security: HSTS，告诉浏览器这个网站在什么情况下应该使用https
X-Content-Type-Options：contentType需要符合一定规则，不然会被阻止
X-Xss-Protection：防止XSS攻击
Referrer-Policy：决定什么时候要发送Referer 这个请求头
Content-Security-Policy: CSP，决定能不能加载某个资源，配置最麻烦

Strict-Transport-Security

# 多少s内浏览器访问该网站应该使用https
add_header Strict-Transport-Security "max-age=63072000;";

X-Content-Type-Options

# X-Content-Type-Options HTTP 消息头相当于一个提示标志，被服务器用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型 的设定，而不能对其进行修改
# nosniff 下面两种情况的请求将被阻止：
# 1.请求类型是"style" 但是 MIME 类型不是 "text/css"， 
# 2.请求类型是"script" 但是 MIME 类型不是 JavaScript MIME 类型。
add_header X-Content-Type-Options 'nosniff';

X-Xss-Protection

# 1 启用 XSS 过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。
# 1; mode=block,检测到之后阻止页面加载
add_header X-Xss-Protection "1; mode=block";

Referrer-Policy

# 决定什么时候要发送`Referer` 这个请求头
add_header Referrer-Policy 'strict-origin-when-cross-origin';

Content-Security-Policy

# 这部分主要根据你们的实际地址和请求来修改，可以直接拿浏览器要的hash值配置
# 需要注意的是script-src不能使用unsafe，即你的网页用的组件不能使用eval，new Funtion等函数  
# 目前我们遇到的是vue需要改成runtime模式  
# 还有一个前端导出excel的组件用到了script-loader，需要修改
# 资源加载策略 default-src 表示默认情况下
# 需要单引号： 
# self：同源 
# unsafe-inline:允许使用内联资源 
# unsafe-eval:允许使用 eval()  
# 不需要单引号 
# data: 协议是data的资源，注意有个冒号(前端加载data:的图片)
# http://10.168.0.114:800 后台地址(处理后台的资源，比如验证码)
# 'unsafe-inline' 'unsafe-eval' data:
add_header Content-Security-Policy "default-src 'self'  http://10.168.0.114:800 ;style-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src-elem 'self' 'unsafe-inline' 'unsafe-eval'; script-src 'self'  'sha256-V4FYFpBUWq0DlvnqicH7btb0sUDUBetG8lXe/6b+UNE=' 'sha256-V4FYFpBUWq0DlvnqicH7btb0sUDUBetG8lXe/6b+UNE=' 'sha256-f/7mRa/vWA+2mOUeu3P2kpWNRe7MZZCqJH5rJuB1I0k=' ; script-src-elem 'self'  'sha256-V4FYFpBUWq0DlvnqicH7btb0sUDUBetG8lXe/6b+UNE=' 'sha256-V4FYFpBUWq0DlvnqicH7btb0sUDUBetG8lXe/6b+UNE=' 'sha256-f/7mRa/vWA+2mOUeu3P2kpWNRe7MZZCqJH5rJuB1I0k='; img-src 'self' data: http://10.168.0.114:800; frame-ancestors 'self'; font-src 'self' data:;";

其他

大多数比如应用程序错误或者整数溢出之类都是说他传了一个非法值，但是返回错误包含了内部异常，处理方法很简单，对系统进行全局异常处理(@ControllerAdvice)，返回一个内部的错误码，而不要把异常直接返回给前端
Cookie相关可以在后端应用中设置SameSite或者Secure
发现可缓存的高速SSL页面，可以通过配置Cache-Control设置
过度的CORS可以在后端配置CORS过滤器的时候不返回*，而是返回特定的Origin
以上都可以通过自己下载一个AppScan自己扫描，生成的报告也有详细的修改建议，但可能有一些规则是安保公司自定义的，这个就得配合安保公司提供的文档测试