防敏感信息泄漏是Web应用防火墙针对网安法明确提出，企业运营者应当采取技术措施和其他必要措施，确保个人信息安全，防止信息泄露、毁损、丢失。
在发生或者可能发生个人信息泄露、毁损、丢失的情况时，应当立即采取补救措施，按照规定及时告知用户并向有关主管部门报告”所给出的安全防护方案。
防敏感信息泄漏功能针对网站中存在的敏感信息（尤其是手机号、***、***等信息）泄漏、敏感词汇泄露提供脱敏和告警措施，并支持拦截指定的HTTP状态码。
事实上做好水平权限控制也是防敏感信息泄漏重要的一环，数据的访问权限，数据脱敏等。防敏感信息泄漏属于DLP数据防泄漏范畴，本文只讨论云waf如何防敏感信息泄漏，DLP范围比较广，后面单独介绍。
网站中常见的造成信息泄漏的场景包括：
URL未授权访问（例如，网站管理后台未授权访问）。
越权查看漏洞（例如，水平越权查看漏洞和垂直越权查看漏洞）。
网页中的敏感信息被恶意爬虫爬取。
针对网站中常见的敏感信息泄露场景，防敏感信息泄漏提供以下功能：
针对网站页面中出现的个人隐私敏感数据进行检测识别，并提供预警和屏蔽敏感信息等防护措施，避免网站经营数据泄露。这些敏感隐私数据包括但不限于***号、手机号、***号等。
针对有可能暴露网站所使用的Web应用软件、操作系统类型，版本信息等服务器敏感信息，支持一键拦截，避免服务器敏感信息泄露。
根据内置的非法敏感关键词库，针对在网站页面中出现的相关非法敏感词，提供告警和非法关键词屏蔽等防护措施。
工作原理
防敏感信息泄露通过检测响应页面中是否带有***号、手机号、***号等敏感信息，发现敏感信息匹配命中后，根据所设置的匹配动作进行告警或者过滤敏感信息。其中，敏感信息过滤动作以*号替换敏感信息部分，从而达到保护敏感信息的效果。
防敏感信息泄露功能支持的Content-Type包括text/*、image/*、application/*等，涵盖Web端、app端和API接口。
针对特定URL页面中的敏感信息过滤：针对特定URL页面中存在的电话号码和***等敏感信息，配置相应的规则对其进行过滤或告警。例如，您可以通过设置以下防护规则，过滤admin.php页面中的***号敏感信息。
我们当前nginx是作为反向代理来使用，在配置proxy_hide_header前，通过浏览器我们可以看到主机响应头中包含php版本信息（X-Powered-By: PHP/5.4.43），我们的目的就是将这个显示内容从响应头中去掉。
请求头：
Host: mytest.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: ccmm_cookie=V1,110015&xxxx&bbb&ccc; appuser=513aaa; MM_DD=1; psessionid=99999; psessiontime=1454552430
Connection: keep-alive
Cache-Control: max-age=0
响应头：
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Thu, 04 Feb 2016 02:20:36 GMT
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.43
根据官网说明，proxy_hide_header 可在http, server, location区段使用。
语法: proxy_hide_header field;
默认值: —
上下文: http, server, location
nginx默认不会将“Date”、“Server”、“X-Pad”，和“X-Accel-…”响应头发送给客户端。proxy_hide_header指令则可以设置额外的响应头，这些响应头也不会发送给客户端。相反的，如果希望允许传递某些响应头给客户端，可以使用proxy_pass_header指令。
一般nginx反向代理会配置很多站点，每个站点配置费时费力而且少有遗漏，主机信息还是会被泄露的。根据上面的说明，我们将proxy_hide_header 配置在http区段，如下所示：
http {
server_tokens off;
server_tag off;
autoindex off;
access_log off;
include mime.types;
default_type application/octet-stream;
proxy_hide_header X-Powered-By;
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 1000m;
client_body_buffer_size 256k;
检查nginx配置文件语法：
/usr/local/nginx/sbin/nginx -t 或/etc/init.d/nginx check重启nginx服务：
/etc/init.d/nginx restart配置后的主机响应头信息：
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Thu, 04 Feb 2016 02:50:16 GMT
Transfer-Encoding: chunked
Vary: Accept-Encoding
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html
Client-Date: Thu, 27 Jun 2019 13:37:33 GMT
Client-Peer: 10.96.3.72:8080
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
使源站返回不压缩response：
在请求时加一个过滤，去掉Accept-Encoding: gzip, deflate请求头，这样源站返回的始终是不压缩的response内容。
waf过滤敏感信息
Nginx实现资源压缩的原理是通过ngx_http_gzip_module模块拦截请求，并对需要做gzip的类型做gzip，ngx_http_gzip_module是Nginx默认集成的， 不需要重新编译，直接开启即可 。
nginx gzip 默认http1.1生效，因为nginx到upsteam回源的请求是http1.0协议，所以gzip version要配置成http1.0
这样在nginx回源的时候，如果rs返回的响应body是压缩的，那么在nginx需要对这个压缩过的body解压，然后过滤body内容，过滤后的内容重新赋给ngx.arg[1]
实现过滤效果。
踩过的坑：
1. 配置gzip version 为http1.1，rs返回的body始终为原body(未压缩)，body_filter阶段得到的始终是原文。
2. rs返回的原body过滤后，在压缩返回client压缩格式的内容，client浏览器显示的始终未压缩body。
3. collections 判断content-lengt type处直接返回。需要修改。
正常思路：
nginx 从upstrean获取到压缩过or未压缩的body(未压缩暂时没完整测试)，判断rs返回的body如果是压缩过的，那么进行解压。
解压后得到原文过滤，然后把过滤后的原文压缩返回给client。即：得到压缩->解压->过滤->压缩->返回。
如果从upstream得到的rsp body为原文，然后过滤→压缩→返回，浏览器显示的始终是压缩格式。为什么这样？总之不可以这样操作。
优化：
在body filter阶段，从rs得到压缩的body，解压赋给ngx.arg[1],然后解压后的原文过滤crs规则，命中规则后，在body_filter文件又得到rs body，然后解压或不解压
然后把命中规则的字段替换掉，敏感信息、手机号等。
rs返回的rsp body为未压缩格式，过滤body然后返回压缩格式的body，待测试。
mime类型判断，动静态文件 压缩解压效果。
未超过gzip min length条件下效果。
语法: gzip_min_length length
默认值: gzip_min_length 0
作用域: http, server, location
设置允许压缩的页面最小字节数，页面字节数从header头中的Content-Length中进行获取。
默认值是0，不管页面多大都压缩。
建议设置成大于1k的字节数，小于1k可能会越压越大。 即: gzip_min_length 1024
gzip_min_length
当返回内容大于此值时才会使用gzip进行压缩,以K为单位,当值为0时，所有页面都进行压缩。
响应时间，主要看压缩解压缩是否占用过多请求时间
压缩效果，原来的5k压缩到1.2k
从这我们可以得出结论：
随着压缩级别的升高，压缩比有所提高，但到了级别6后，很难再提高；
随着压缩级别的升高，处理时间明显变慢;
gzip很消耗cpu的性能，高并发情况下cpu达到100%;
因此，建议：
不是压缩级别越高越好，其实gzip_comp_level 1的压缩能力已经够用了，后面级别越高，压缩的比例其实增长不大，反而很吃处理性能。
压缩一定要和静态资源缓存相结合，缓存压缩后的版本，否则每次都压缩高负载下服务器肯定吃不住。
gzip_disable
通过表达式，表明哪些UA头不使用gzip压缩
gzip_proxied
Nginx做为反向代理的时候启用：
off – 关闭所有的代理结果数据压缩
expired – 如果header中包含”Expires”头信息，启用压缩
no-cache – 如果header中包含”Cache-Control:no-cache”头信息，启用压缩
no-store – 如果header中包含”Cache-Control:no-store”头信息，启用压缩
private – 如果header中包含”Cache-Control:private”头信息，启用压缩
no_last_modified – 启用压缩，如果header中包含”Last_Modified”头信息，启用压缩
no_etag – 启用压缩，如果header中包含“ETag”头信息，启用压缩
auth – 启用压缩，如果header中包含“Authorization”头信息，启用压缩
any – 无条件压缩所有结果数据
如果源站配置成http1.1 才返回压缩的body，那么waf受到的响应为未压缩的格式。
如果此时的http请求为Accept-Encoding:gzip, deflate，那么waf在向client回应body时，会有Content-Encoding: gzip响应head。
waf处理逻辑得到响应head Content-Encoding: gzip，然后把rs返回的body压缩返回给client。
增加处理逻辑，在判断rs返回body为未压缩格式，http请求有请求为Accept-Encoding:gzip, deflate，即使有Content-Encoding: gzip响应head，也不压缩body。
进一步：如果rs返回未压缩，waf也压缩body，client浏览器显示压缩过的乱码。
*本文作者：stan1y，转载请注明来自FreeBuf.COM
来源：freebuf.com 2020-06-28 10:00:58 by: stan1y
请登录后发表评论
注册