一、概述

安全审计可以由第三方公司或者本公司安全审计软件进行，其目的是检测潜在的威胁点，帮助系统从 Web 端、APP端、服务器运行环境等提升一个安全维度。

二、Web端

2.1、IP资产信息

解决方案：建议隐藏真实IP，使用CDN 和配置 vhost隐藏证书信息。请酌情处理。

http://www.idcspy.com/hidden-ip.html

修改ngnix配置CDN 和配置 vhost隐藏证书信息。

2.2、注册安全策略

解决方案：

1、加强密码规则，建议加入大小写字母与特殊字符。

2、验证码设置过期时间，并且后端强制验证时效性。

2.3、登录安全策略

解决方案：登录应进行二次验证，注册完成后应强制开启 2FA。当用户登录时，除了输入相应的密码，还需要输入手机短信验证码验证或者谷歌身份验证器验证，进而确保账户安全。

2FA：2 Factor Authentication，双因子验证，是一种安全密码验证方式。用户登录的时候除了输入密码，还需要手机短信验证码验证或谷歌身份验证器验证（私人信息+个人物品）。

币赢使用的2FA方式有两种：

手机短信验证码验证和谷歌身份验证器验证。您在登录时需要输入作为第一次验证的登录密码和作为第二次验证的2FA验证码（手机短信验证码或谷歌身份验证器动态密码），为您的账户设置双重保护。为了您的账户安全，在您绑定手机或谷歌验证器后，将默认开启登录2FA。

区别于传统的密码验证，由于传统的密码验证是由一组静态信息组成，如：字符、图像、手势等，很容易被获取，相对不安全。

双因素认证总结

1、优点

比单纯的密码登录安全得多。就算密码泄露，只要手机还在，账户就是安全的。各种密码破解方法，都对双因素认证无效。

2、缺点

登录多了一步，费时且麻烦，用户会感到不耐烦。而且，它也不意味着账户的绝对安全，入侵者依然可以通过盗取 cookie 或 token，劫持整个对话（session）。

3、帐户恢复问题

这是双因素认证最大的一个问题。

一旦忘记密码或者遗失手机，想要恢复登录，势必就要绕过双因素认证，这就形成了一个安全漏洞。

除非准备两套双因素认证，一套用来登录，另一套用来恢复账户。

2.4、数据传输安全

解决方案：对于敏感信息，应加密后进行传输。密码使用前端JS使用RSA公钥加密后，然后转成BASE64的可读字符，传给后端使用私钥解密.

Uncaught ReferenceError: RSAEncrypt is not defined

<%--RSA加密--%>

<%@include file="./../comm/jsencrypt.jsp" %>

2.5、2FA安全策略

2.6、会话安全策略

2.7、交易安全策略

资金划转精度前后端保持一致

2.8、 防钓鱼策略

2.9、KYC 安全策略

含义：KYC（know your customer）:

问题描述：

1、身份证号可进行枚举，抓包通过更改身份证号，若已经实名认证通过的会提示已存在。

黑客抓包原理：

先了解一下http和重定向的原理，如下图所示：

客户端向服务器发送请求的时候，如果服务器重定向的话，会在响应头中设置302重定向状态码，location字段设置重定向地址，然后返回给客户端，客户端收到302状态码后会直接在本地浏览器访问location中的地址，即实现了两次请求。

例如aboutme页面，我们通过访问about可以进行重定向跳转到aboutme页面，访问路径发生了变化，即实现了重定向。

公共免费wifi真的不要随便连。假设有黑客开放了一个免费wifi，当我们连接使用公共wifi时，便和黑客处于同一网段下了，我们手机app往服务器发送的所有请求都要经过黑客的网卡，这时的情况就非常的危险。市面上多数app底层都使用的http协议，并且使用明文连接，未采用加密措施，这也就意味着当黑客使用抓包工具拦截我们的请求时，可以随意修改请求数据。例如我要支付10元，支付请求被拦截后，黑客可以轻易的将10元的参数改为10000元，仅仅是需要手动加上三个0，再重定向到服务器，钱随着黑客扬长而去，留下一脸问号的你。

再者，短信中的一些链接也不能随便点击。有些人用笔记本伪装成手机运营商，利用2G网络漏洞大量发送虚假短信，因为只能在伪基站一定范围内发送，所以这类人一般会整个小黑破包，骑个小破摩托到处跑，2b得让人受不了。当然现在2G网络已经基本废弃，这个问题也得到了修复。

解决方案：

1、应该对提示进行模糊处理，而不是直接提示 “身份证号码已存在”。现提示为“您输入的信息有误”。

2、在提交审核后，不应再允许重复提交，除非审核结果要求再次提交。

3、检查上传文件内容。

2.10、AML安全策略

2.11、HTTP头安全检查

解决方案：酌情添加缺失的安全头。

https://blog.csdn.net/niuch1029291561/article/details/86705141

实现方案：

在全局过滤器中增加如下代码：

resp.addHeader("x-frame-options","SAMEORIGIN");//防止x-frame-options

resp.addHeader("Strict-Transport-Security","max-age=86400");//增加HTTP Strict-Transport-Security 头

resp.addHeader("X-Content-Type-Options","nosniff");//增加“X-Content-Type-Options”头

resp.addHeader("X-XSS-Protection","1; mode=block");

注意：加了之后测一下其他流程是否会受到影响（跟session和cookie相关的）

2.12、SSRF漏洞

解决方案：

1、设置URL白名单且限制内网IP。

2、禁止跳转。

3、过滤返回信息。

修改显示只能http或者https协议，禁用其他协议，并且不能访问后端服务。

2.13、量化后台敏感泄露

解决方案：限制访问规则。建议统一处理错误页面，将错误信息存储在日志中。 

注：

 敏感信息泄露漏洞，是一种通过提交错误请求，使系统出现异常处理并报错，并且将系统程序、配置 等敏感信息泄露出来的漏洞。工程师发现系统搜索功能模块中普遍将系统的报错通printStackTrace 方法进行反馈，可造成报错信息如实的返回到前端。 

攻击者可以利用此漏洞收集系统报错中泄露的数据信息，包括处理函数，系统版本等等。可以通过此类问题获得深入和更有目的性攻击的条件。

2.14、SQL注入

创建拦截器

判断是否有攻击串（delete|truncate）

2.15、限制密码错误次数

接口没限制交易密码错误尝试，如果交易密码8位数且只是字母+数字，可以暴力破解交易密码。

2.16、系统安全之密码密文传输

问题场景：

设置交易密码时，交易密码明文传输。

解决方案

设置与使用交易密码时对数据进行加密处理（如加盐的MD5哈希）

包括web(front)和h5(phone)

具体处理

前端RSA公钥加密，后端RSA私钥解密，

后端

originPwd =new String(RSAUtils.decryptByPrivateKey(Base64.decode(originPwd), Constant.RSA_PRIVATE_KEY));

前端JS：

originPwd =RSAEncrypt(originPwd);

2.17、数据验证安全

后端有，前端可无

后端验证一定要有，是因为后端才是接收数据，并对数据进行操作和存储的。只要保证了接收到的数据有足够的验证，就能保证最终存储的数据是满足了业务验证条件的，不是“脏数据”。

如果仅有前端验证，没有后端验证。在前后端分离的情况下，用户可以绕过前端，直接访问后端接口。那么前端验证也就失效了。也就等于没有对数据的业务验证了