最近处理了很多安全工单，所以趁着机会梳理了下。安全是业务的最低下限，必须予以重视～

1. 业务安全

1. 并发请求

当存在写操作的接口设计时未考虑幂等性或者实现时未保证接口的原子性的时候，就会出现重放&并发漏洞

举例：业务提供一个点赞或者收藏的接口，接口中仅仅判断登陆态后就执行了增加点赞的操作

1 2	isLogin($this->openID, $this->accessToken) // 校验登陆态 addGood($this->contentID) // 给具体内容点赞，基本操作是计数器++

那么并发调用该接口的时候就会导致异常数据
解决思路: 业务接口都带唯一的token，然后根据token进行幂等判断

2. 越权

何谓越权：
越权漏洞是指应用程序未对当前用户的身份权限进行严格校验，导致用户可以操作超出自己权限范围的功能。

举例1：

1 2	isLogin($this->openID, $this->accessToken) // 校验登陆态 uid = $_GET['uid'] // 从请求参数中获取用户的唯一标识

登陆态是A用户的，然后uid修改为B用户的，这样可以操作B用户的数据

举例2:

1 2	isLogin($this->openID, $this->accessToken) // 校验登陆态 modifyAddress($this->addressID, "xxxxxx") // 修改制定地址为xxxx

用户A的登陆态校验通过后就修改addressID的地址内容，但是这个addressID可能不是用户A添加的
解决思路：
（1）从登陆态中获取用户uid
（2）严格校验当前用户登录态中uid是否有对应资源id的操作权限

3. 敏感信息泄漏

通过网站、接口、外部存储等途径，将用户个人信息、企业员工信息、内部资料等数据泄露到外部。

举例1:
接口中因为考虑到”扩展”的需要，返回了不需要用到的信息，比如银行卡号、身份证号等
举例2:
向外部提供接口的时候未限制访问来源，也没有鉴权，导致用户或者商户的信息泄漏
举例3:
业务需要的敏感信息，但是未做脱敏展示，比如中奖公示页面展示用户完整的手机号或QQ号

解决思路:
（1）设计接口的时候，按照迪米特原则或者奥卡姆剃刀，没有用到的字段不要返回～
（2）对外合作的接口一定要增加访问白名单或者鉴权
（3）对于一定要展示的用户敏感信息进行数据脱敏（Data Masking），顾名思义，是屏蔽敏感数据，对某些敏感信息（比如，身份证号、手机号、卡号、客户姓名、客户地址、邮箱地址、薪资等等）通过脱敏规则进行数据的变形，实现隐私数据的可靠保护。业界常见的脱敏规则有，替换、重排、加密、截断、掩码，用户也可以根据期望的脱敏算法自定义脱敏规则。动态数据脱敏，在访问敏感数据的同时实时进行脱敏处理，可以为不同角色、不同权限、不同数据类型执行不同的脱敏方案，从而确保返回的数据可用而安全。

4. 逻辑漏洞

逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞，在交易支付方面主要体现为金额和数量的任意修改

举例1:
订单商品的数量或者金额依赖前端传入而非服务端计算，导致攻击者可以修改数据包参数

举例2:
购买商品的逻辑一般是扣款发货，不能将顺序颠倒改为发货后扣款，如果扣款失败而且没有回补机制会造成损失

解决思路:
（1）业务的核心参数应该由服务端计算而不是依赖客户端传入
（2）核心逻辑一定要保证顺序性，最好是引入强制 code review 机制

5. 密钥硬编码

在代码中硬编码了各类密钥(如各类PaaS/SaaS产品的API密钥、数据库凭证密钥、加密私钥凭据等)，攻击者通过窃取源代码或逆向应用提取敏感密钥后，可伪造操作人身份发送恶意信息、进一步控制各类云资产，甚至大量脱取业务敏感数据，产生高危甚至严重风险

举例1:
客户端在微信登陆的相关逻辑中保存了 appsecret,代码被反编译后导致微信开放平台接口可以被恶意调用

举例2:
服务端代码中硬编码了数据库的密码，然后不小心提交到外部的代码托管平台，造成数据的泄漏

解决思路:
（1）客户端不要保留任何密钥，如果需要调用第三方组件功能的时候交由服务端处理
（2）服务端密钥需要托管在专门的密钥管理系统或者配置系统中

6. 云存储上传& CDN 流量被刷

当 COS 配置不合理（如：公有读写，且没有配置防盗链）或者业务的上传接口对于用户上传内容的大小，类型或者内容等没有限制的时候，黑客可以利用业务的存储空间来存放自己的文件，为他人提供免费的文件下载服务等，甚至可以利用公司的 CDN 建立盗版源，造成公司资源大量浪费

举例1:
业务配置 cos 不合理，被别人上传了文件，然后通过 cdn 访问，从而给业务带来了较大的损失

举例2:
业务没有对上传的内容（图片或者视频）进行审核就放出，导致被用作传播违法违规内容的跳板

解决思路：
（1）cos 桶需要配置私有读写，而且需要加上防盗链
（2）需要对用户上传的权限/频率和类型作限制
（3）需要接入内容安全能力
（4）CDN 的使用最好是业务互相隔离，业务A使用的appid不能被业务B的域名所使用

7. 管理后台对外

内部使用的管理平台可以被公网所访问。内部管理平台拥有特殊的权限或者敏感的数据，被暴露在公网可能会导致信息泄漏或者越权操作

举例1:
职员小A离职后仍然具备管理后台权限，而且管理后台可以公网访问。这样小A就可以给自己添加额外的权限或者查询到不应查询到的数据

举例2:
使用开源软件搭建的管理后台忘记修改初始密码，被恶意登陆导致信息血流或者数据被篡改

解决思路:
(1) 管理后台尽量使用内网，如果实在要开通外网就做好登陆认证/白名单校验等
(2) 员工离职后及时清理权限

2. 数据安全

1. sql 注入

根据用户输入的参数拼装生成SQL语句并执行，黑客可通过传入恶意参数值注入自己定义的语句，使数据库执行任意自己需要的指令，实现数据窃取或入侵破坏

举例1:
某业务将用户的昵称和头像存在 mysql 中, 修改的时候采用了 sql 拼装的方式。当没有验证参数的时候，可能导致 mysql 中所有的昵称和头像被修改为恶意的

解决思路:
(1) 校验输入参数
(2) 禁止拼接 sql，改为采用预编译的方式

2. 敏感信息加密

用户敏感信息存储的时候需要进行加密，比如身份证/手机号等

举例1:
sql 注入导致敏感信息泄漏

举例2:
mysql 账号密码写在了公开的代码托管仓库或者网络笔记上，导致敏感信息泄漏

解决思路:
(1) 敏感信息加密存储, 获取的时候通过解密函数解密，同时外显的时候做好脱敏处理

3. 弱口令

密码设置的安全性不够（比如全部是纯数字或者纯字母），可以通过密码表或者暴力破解

解决思路:
(1) 数字字母特殊字符，字母大小写，长度保持12位及其以上