一、背景说明

金融类APP的安全整改，为了提高APP的安全性，达到相关机构的安全标准做的改进。先写个提纲，以后慢慢补充细节

二、改动项整理


	
报文加解密(RSA+AES，密钥安全保存)、防重放
	
	
双向证书认证
	

	
开启混淆，应用签名检测防止二次打包
	
	

	
登录密码复杂度
	
	

	
第三方sdk初始化放在同意隐私协议之后
	
	

	
权限整改，隐私政策整改
	
	

	
APP的环境检测：模拟器/Root
	
	

	
本地重要信息加密存储(如SP加密存储)
	
	

	
业务整改(如允许用户注销账号)

	
 

	
 

	
 

	
 
	

最近项目组安全整改，然后需要把所有的安全隐患问题一扫而空，其中也踩了不少的坑，记录下来，以便后续遇到类似问题能立马解决


CSP
CSRF


CSP全称Content Security Policy，主要限制图片资源、css资源、js资源的加载

设置方式
# 使用meta标签
<meta http-equiv="Content-Security-Policy" content="font-src 'self' data:; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; default-src 'self';">
    
# 在服务端的Nginx配置里面加上header
add_header Content-Security-Policy "font-src 'self' data:; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; default-src 'self';"

Tips：self表示加载自身网站的资源，xxx-src表示限制某种类型文件加载的名字（font-src表示字体文件iconfont加载），然后有一些小图片资源编译成base64，然后采用的协议是data:image/png;base64,xxx所以需要在img-src里面将data:放通。有一些产品线需要进行网站数据的埋点，需要引入第三方的js，那么就需要在对应的script-src里面放通对应的域名https://xxx.com。(而且域名不需要加上单引号)
这两种方法，实践告诉我们，使用meta标签最优，为什么呢?因为如果你往服务器的响应头里面设置，那么每个请求都带上对应的信息，既浪费了带宽，也降低了网页的访问效率，而且给低速的网络的设备增添了不少压力。


CSRF：众所周知的跨站伪造攻击。为了防护，需要给每次的请求带上唯一的Token。那么这里涉及到几个问题，设置的时机还有扩展性。比方说，跨部门单点登陆的时候怎么办？token怎么携带过去，文件资源需要下载到本地怎么办？

解决方案
# 单点登陆
 - 协商多平台使用同一个API获取Token，每次登陆成功后请求该API获取Token
 - 同域名下通过url传参、session方式
 - 跨部门的话通过一个双方协商好的登陆中转站进行跳转（所谓中转站就是弄出一个页面，然后里面做一些平台鉴权的访问，通过鉴权之后就可以直接跳转到其它部门的网站里面。但是这里需要注意的是同步上线的问题，而且文件每次都需要加上唯一标识符）

# 文件下载
 - 通过form表单提交直接下载，如果需要带上token的话，在url里面带上（表单不支持设置header头）
 - 通过xhr、blob、a标签进行下载，token在xhr请求的时候设置上

/*
 * 文件下载代码
 * 需要注意的是，后台返回来的文件名是通过Content-Disposition获取的，大概是这样
 * Content-Disposition: xxx;filename="xxxxx.ppt";所以有要对文件名获取的操作
*/ 
let fileNameReg = /(?=filename=([^.]+(?:\.[a-z]+)?))/;

/**
 * 下载文件函数
 * @param {String} url
 * @param {Object} opt
 * - header { key: value }
 * - method 'get' || 'post'
 * - responseType  '' | 'arraybuffer' | 'blob' | 'document' | 'json' | 'text';
 * - params { key: value }
 */
function downloadFile (url, opt) {
    let xhr = new XMLHttpRequest({
        responseType: opt.responseType || 'json'
    });
    url  = formateURL(url, opt);

    xhr.onreadystatechange = () => {
        if (xhr.readyState === +'4' && xhr.status === +'200') {
            let responseHeader = xhr.getResponseHeader('Content-Disposition');
            let fileName = '';

            if (typeof xhr.response === 'string') {
                try {
                    let {
                        message: msg,
                        code,
                        data
                    } = JSON.parse(xhr.response);

                    opt.cb({
                        msg,
                        code,
                        data,
                        success: code === 0
                    });
                } catch (e) {

                    //ignore
                }
            }

            if (responseHeader) {
                fileName = decodeURI(responseHeader).match(fileNameReg)[1];
                download(new Blob([xhr.response]), fileName);
            }
        }
    };

    xhr.onerror = () => {
        xhr = null;
        if (typeof opt.cb === 'function') {
            opt.cb({
                msg: 'Network Error',
                code: -1,
                success: false
            });
        }

    };
    xhr.ontimeout = () => {
        xhr = null;
        if (typeof opt.cb === 'function') {
            opt.cb({
                msg: 'Request Timeout',
                code: -1,
                success: false
            });
        }

    };

    xhr.open(opt.method, url);
    xhr.timeout = opt.timeout || +'60000';
    let params = formateParams(xhr, opt);
    setRequestHeader(xhr, opt.header);
    xhr.send(params);
}



function download (blob, fileName) {
    if (window.navigator && window.navigator.msSaveOrOpenBlob) {
        window.navigator.msSaveOrOpenBlob(blob, fileName);         // 兼容IE
    } else {
        let link = document.createElement('a');
        link.href = window.URL.createObjectURL(blob);
        link.download = fileName;
        document.body.appendChild(link);
        link.click();
        window.URL.revokeObjectURL(link.href);
        document.body.removeChild(link);
    }
}

/**
 * 设置请求头
 * @param {XMLHttpRequest} xhr
 * @param {Object} headers
 */
function setRequestHeader (xhr, headers) {
    setValue(headers, (key, value) => xhr.setRequestHeader(key, value));
}

function formateParams (xhr, opt) {
    let {
        params,
        method
    } = opt;

    if (params && method === 'post') {
        let str = '';
        setRequestHeader(xhr, { 'Content-Type': 'application/x-www-form-urlencoded;charset-UTF-8' }); // POST请求需要带上这个Content-Type
        setValue(params, (key, value) => str += '&' + key + '=' + encodeURIComponent(value));
        return  str.replace(/&/, '');
    }
    return null;
}

/**
 * 格式化URL
 * @param {String} url
 * @param {Object} opt
 * @return {String} url
 */
function formateURL (url, opt) {
    let {
        params,
        method
    } = opt;
    if (params && method === 'get') {
        let str = '';
        setValue(params, (key, value) => str += '&' + key + '=' + encodeURIComponent(value));
        url += str.replace(/&/, '?');
    }
    return url;
}

/**
 * 设置key和value
 * @param { Object } target {key:value}
 * @param { Function } cb function(key, value)
 */
function setValue (target = {}, cb) {
    Object.entries(target).forEach(row => {
        let [key, value] = row;
        cb(key, value);
    });
}

export {
    downloadFile
};

目前公司多个项目需要进行安全整改，因为客户在交付之前要求进行等保测试，现在尤其是政府单位或是国企在安全上的要求越来越高了，可能也是这些单位一旦被攻击，后果可能比较严重，所以要求都比较严格，等保测试一般分为黑盒测试和白盒测试，黑盒测试一般为安全扫描，功能测试，功能测试这里就不说了，而白盒测试则为静态代码扫描。

安全扫描
安全扫描常见问题

tomcat默认配置
泄露tomcat默认配置页面
泄露tomcat版本信息

非正常手段占据tomcat资源


session长时间未失效

关闭不安全的http方法


refers未校验
会话标识未刷新
XSS注入
SQL注入
敏感信息未加密
请求头缺失问题
文件上传漏洞

如何处理这些问题
以上问题主要可以分为三类问题，这三类问题主要是

web服务器安全漏洞（不同的平台有各自的漏洞，IIS、apache、weblogic、tomcat）
会话漏洞
注入漏洞
接口安全

如何处理web服务器安全漏洞
这里主要针对tomcat进行处理，目前最简单的做法就是 删 ，删除tomcat\webapps下的所有文件夹，很多的安全扫描软件，会针对市面上主流的web服务器做一些深入的测试，所以将这些非必须的文件删除掉比较好，可以省去很多问题，用AppScan扫一下会发现少了很多问题。
在http请求中会泄露服务器的版本信息，某些特定版本的服务器有些固定的漏洞，所以最好将服务器版本升级到最新的安全版本，或者隐藏服务器的版本信息。
tomcat配置文件中默认的请求时长为20000毫秒，这样的请求时长还是比较长的，通过一些特定的请求方式（低网速环境下请求），在tomcat连接数量固定的前提下，同时发起大量的长连接，会导致tomcat连接资源被迅速耗尽，通过修改请求时长可以解决这个问题。
如何处理会话漏洞
会话漏洞，主要通过非常规手段获取会话标识，通过会话标识模拟登陆，从而实现登陆，目前主流的会话状态保持方式有通过session、token的方式，session的方式更为常见，因为使用简单方便，关于session的问题主要为session过期问题和session会话凭据问题：


session长时间未过期
可以通过配置tomcat设置session过期时间，也可以在代码中创建session时指定session的失效时间。


session会话凭据未刷新
可以通过拦截器或是filter强制刷新会话标识。


如何处理注入漏洞

注入漏洞存在很久，随着项目的依赖的变化，注入的内容也可能发生变化，所以这里推荐使用黑名单的方式处理特定的注入字符串，但是可能会导致一些正常的接口发生异常。

关于注入问题，都是通过拦截器或是过滤器的方式统一对所有的请求进行过滤，将黑名单的中的非法字符串过滤掉。
如何处理接口安全

永远不要相信客户端提交的数据，我们只应相信服务器端的数据，所有提交至后端的数据都应该进行校验，而不是直接使用。

如何防止自己的接口被滥用，比如自己的接口被别人盗用了，通过校验refer可以判断是否被盗用，在拦截器中进行校验。
如何加密敏感信息，这里推荐使用AES对敏感信息进行加密，其实网页端对敏感信息加密的作用不大，应为秘钥肯定是要写在HTML当中的，第三方可以通过抓包获取到敏感信息，那么从网页中提取出AES秘钥应该也没什么问题，但是对于客户端应该是有作用的。
对于文件上传部分需要特别注意：

需要限定可上传文件的类型，不要通过后缀名进行简单判断；
需要限定上传文件可保存的目录，防止服务器文件目录被恶意遍历；
需要限定上传接口的权限，防止恶意上传大文件。

静态代码扫描
静态代码扫描常见问题

变量命名方式（命名方式及是否占用敏感词）
if判断不要省略括号
文件或流操作要添加异常处理
try catch 中需要具体化异常类型
部分静态代码扫描工具会对代码中出现的特定敏感单词报错（比如 pwd、password）

生产事故
for循环中调用DAO层

当时的情况是系统偶发性的数据库服务器CPU飙升到100%，而且会经久不衰，数据库服务器重启后还会迅速飙升到100%，导致这个问题的原因有2个，一个是频繁的创建数据库连接，耗尽数据库资源，导致数据库服务器CPU飙升到100%，而service滥用事务又导致了数据库中积累了大量未执行完的事务，导致重启后CPU又快速飙升到100%。

事故简介，一个主表有时候需要关联多条子表数据，最常见的是订单主表与订单字表，以及关联用户信息表，大致数据结构可以分为以下：
class User {
    String userid;
    String username;
}

class Detail {
    String orderid;
    String detailid;
    String prdid;
    String prdname;
    int prdnum;
}

class Order {
    String orderid;
    String userid;
    Date createdate;
    int orderstatus;
    String orderstatusname;
    User user;
    List<Detail> details;
}

面对这样的数据结构，如果需要导出1000条订单的详细信息，获取主表信息会非常的简单，直接就可以获取了，但是订单用户详细信息及订单字表信息该如何获取呢？如果通过for循环获取，会导致一系列的问题，其实如果一切交给交给spring应该也没什么问题，但是如果你是手动管理数据库session的话，则会导致频繁的创建和销毁session，而且项目整体没有对连接数量做出限制。
这样的问题该如何解决呢？最简单的方法可能是交给spring来管理，spring的作用就是管理你的代码的下限，但是频繁的调用也有可能导致问题，目前解决这个问题的方式我想出了2个思路：

创建视图，在视图中整理出你需要的数据结果；
通过mybatis关联查询，这个相对来说可能会好一点。

事务的不正确使用
目前接触到的项目中的关于事务的操作方法主要有2中，一种是通过session手动控制，在代码发生异常时，统一回滚，或者使用spring提供的transestional 注解进行自动回滚，首先我们要知道我们为什么使用事务，使用事务主要是为了业务的原子性，比如说在销售的时候，订单需要与商品库存保持一致，这就要求，只有在订单保存成功的前提下库存数量才能变化，那么那些操作需要使用到事务呢？
事务一般使用在一个业务需要修改多张表数据时，各个表的数据修改之间存在一定的关系，所以不要在查询业务中使用事务，滥用事务，会消耗数据库服务器的CPU资源。
敏感接口未添加校验

这个事故可以算是被入侵了，用户通过跨域请求短信发送接口，将系统中的短信接口作为一个短信群发接口。

其实这个问题已经被各个应用广泛的处理了，那就是添加图形验证码，进行防刷操作。
linux常见命令要学会
这次事故，教育我要好好的悬系linux命令，简单的说一下，就是应用服务器磁盘已满导致的nginx无法显示图片。
最后安利下自己的小程序，一款程序员刷题小程序。

【环境介绍】
系统环境：Linux + mysql 5.7.18 + 主从复制架构
【背景描述】
需求：MySQL数据库都有每年的集团安全整改，常常要求弱口令扫描，基线扫描，漏洞扫描等等。对于MySQL的基线配置检查中的日志方面也是有好几个要求，建议开启MySQL的各种日志配置，记录数据库的各种类型活动，便于处理数据库故障和性能优化都有很大的帮助。开启这配置提供了帮助的同时也同时产生一定的性能消耗和存储方面的消耗。
【MySQL日志配置大致介绍】
类型
介绍
作用
参数
错误日志
记录对数据库的启动、运行、关闭过程进行记录信息
记录告警或正确信息
log_error
二进制日志
记录对数据库执行更改的所有操作，不包含select和show类型操作信息
用于恢复，复制，审计
log_bin
慢查询日志
记录对数据库执行长的SQL操作信息
定位存在问题的SQL，从SQL语句层面上进行优化
slow_query_log
通用查询日志
记录对数据库请求的所有操作信息
用于恢复，审计
general_log
更新日志
记录从主服务器接收的从服务器的更新是否应该记录到从设备自己的二进制日志
用于复制
log_slave_updates
【MySQL日志配置配置】
错误日志：默认开启，初始化时指定错误日志路径。/etc/my.cnf 参数文件设置：log_error = /home/mysql/logs/mysql.err
二进制日志：可关闭，可开启，全局静态参数。log_bin = /home/mysql/logs/binlog
慢查询日志：可开启可关闭，全局动态参数。
set GLOBAL slow_query_log_file = '/home/mysql/logs/slow.log'; set GLOBAL slow_query_log = ON;
通用查询日志：可开启可关闭，全局动态参数。
set GLOBAL general_log_file = '/home/mysql/data/oracle.log'; set GLOBAL general_log =ON;
更新日志：可关闭，可开启，全局静态参数。/etc/my.cnf 参数文件设置：log_slave_updates = ON
安全检查建议开启全部的日志配置。在整改的过程中，开启这些日志消耗性能是一定的，其中，通用查询日志的消耗最明显，产生的日志量的问题也是很常见。咨询业务侧，该数据库的业务比较繁忙，那么通用查询日志的问题就比较显著，进行对通用日志处理。
【通用日志处理】
于是对通用日志产生的日志量的问题进行处理。
需求：开启通用日志，每周日定时清理日志，保存3份有效日志记录备份，记录清理日志。
测试最终效果如下：
主要实现功能的脚本如下：
cat > mysql_generlog_clean.sh
######################################################################
# mysql_generlog_clean.sh
# This script is clean mysql generlog
# Author CZT
######################################################################
#!/bin/sh
mysqladmin=`which mysqladmin`           ---定义mysql命令环境变量
mysql=`which mysql`
user="root"                                             ---注意进行操作的用户权限
passwd="xxx"
time=`date +%Y%m%d%H%M`
general_log=`mysql -u${user} -p${passwd} -Ne "show variables like 'general_log_file';" 2>/dev/null |grep general_log_file|awk '{print $2}'`           ---取当前设置通用日志的日志路径
mv ${general_log} ${general_log}_bak.${time}
mysqladmin -u$user -p$passwd flush-logs general 2>/dev/null
gzip ${general_log}_bak.${time}              ---对历史通用日志进行压缩
var_count=`ls -lrt ${general_log}_bak*|wc -l`
if [ $var_count -gt 3 ]
then
echo "gt 3"
var_del_count=`expr $var_count - 3`        ---判断保留3份历史日志
ls -lrt ${general_log}_bak* |awk '{print $9}'|head -$var_del_count> del_bakfile_list.txt
while read LINE
do
echo $LINE
rm -f $LINE                                            ---删除旧日志备份文件
done
else
echo "lt 3"
fi
【问题思考】
1，  对于产生的空间大小一定要经过测试，不同的业务产生的影响也有所不同，系统空间问题由于权限限制，不能限制空间，只能手动制定策略；
2， 因为备份中有切换日志操作，对日志备份清理的时间点避免业务高峰期间，防止期间造成告警报错，时间点的选择也是非常重要的环节；
3， 对于参数调整，必须了解该参数属性，是否可以实时开启关闭，对应急处理有非常大的帮助。
【总结】：
1，  对于安全整改配置时，一定要评估好风险，防止产生问题；
2，  对于日志量的问题，脚本可以举一反三处理；
3，  对于安全整改配置时，必须全面了解参数属性，便于应急的处理。