- [1. 验证码](#1-验证码)
  - [1.1. 用户登录](#11-用户登录)
    - [1.1.1. 撞库漏洞](#111-撞库漏洞)
    - [1.1.2. API 登录](#112-api-登录)
    - [1.1.3. 用户注册](#113-用户注册)
    - [1.1.4. 密码找回的安全设计思路](#114-密码找回的安全设计思路)
  - [1.2. 资料查看与修改的安全设计思路](#12-资料查看与修改的安全设计思路)
  - [1.3. 投票/积分/抽奖的安全设计思路](#13-投票积分抽奖的安全设计思路)
  - [1.4. 充值支付的安全设计思路](#14-充值支付的安全设计思路)
  - [1.5. 私信及反馈的安全设计思路](#15-私信及反馈的安全设计思路)
  - [1.6. 远程地址访问的安全设计思路](#16-远程地址访问的安全设计思路)
  - [1.7. 文件管理的安全设计思路](#17-文件管理的安全设计思路)
  - [1.8. 数据库管理的安全设计思路](#18-数据库管理的安全设计思路)
  - [1.9. 命令/代码执行的安全设计思路](#19-命令代码执行的安全设计思路)
  - [1.10. 文件/数据库备份的安全设计思路](#110-文件数据库备份的安全设计思路)
  - [1.11. API的安全设计思路](#111-api的安全设计思路)

# 1. 验证码

- 验证码有图片验证码、滑动验证码、短信/邮箱/电话、二维码等分类
- 而据保守估计起码有80%以上的验证码是存在可以爆破和简单识别的问题，设计一个有效的验证码尤为重要

**验证码不刷新导致直接绕过**

- 验证码能够多次使用的原因是后端程序在接收一次请求后，并没有主动刷新验证码
- 部分比较大的业务使用了负载均衡，验证码跟Session绑定在一起，为了能够保证验证码能够正常使用，所以会把验证码明文或者加密后放在Cookie或者POST数据包里面
- 所以每次只要同一个数据包里面的两个验证码对上了即可绕过

**验证码暴力破解**

- 注册或者找回密码等敏感操作时的手机或者邮箱验证码能够爆破
- 主要是因为程序没有设置验证码错误次数和超时，导致能够不断进行尝试

**验证码机器识别**

图片验证码的机器识别，有两种情况：

- 一种是针对不是实时生成的验证码，已经生成了部分的验证码在服务器端保存，前端直接加载验证。这类是最好绕过的，只要把全部的验证码文件保存回来，做一个图片MD5库，然后利用的时候直接匹配服务器端返回的图片MD5即可识别。
- 另外一种是动态生成的验证码，这类需要做一些图片文字识别或者语音识别

**验证码打码平台**

> 打码是网络兼职数据录入工作的一种，指通过人工识别并输入验证码以协助自动化程序绕过[图灵测试](https://baike.baidu.com/item/图灵测试/1701255?fromModule=lemma_inlink)的行为，常见于批量注册账号、群发广告等场景。

**强壮的验证码**

1. 设置验证码错误次数
2. 不把验证码放到HTML页面或者Cookie中。
3. 验证码要设置只能请求一次，请求一次后不管错误与否都在后端程序强制刷新。
4. 短信或者邮件验证码必须要6位以上字母和数字混合，图片或者语音验证码要加强混淆干扰，比如图片文字变形，增加干扰斑点等。语音验证码增加背景噪声。
5. 验证码要动态生成，不能统一生成多次调用

## 1.1. 用户登录

### 1.1.1. 撞库漏洞

撞库漏洞是指登录口没有做登录次数限制，导致可以使用不同的用户及密码进行不断的登录尝试，以遍历用户密码；也可以理解为登录爆破。

- 用户名和密码错误次数都无限制
- 单时间段内用户的密码错误次数限制
- 单时间段内IP登录错误次数限制
- 针对撞库漏洞比较好的解决方案是使用登录验证码和多因素认证

### 1.1.2. API 登录

- 登录密钥(clientkey)需要不可预测并且不固定，生成key的算法中加入随机字符。
- API接口禁止搜索引擎收录。
- 登录密钥当次绑定当前主机，换机器不可用，防止QQ木马和嗅探key。

案例：193页

### 1.1.3. 用户注册

垃圾注册，机器注册是比较头痛的问题。如何抵御恶意注册？

1. 设计验证码采
2. 集用户机器唯一识别码，
3. 拦截短时间内多次注册
4. 根据账号格式自学习识别垃圾账号
5. 防止SQL注入漏洞与XSS漏洞

### 1.1.4. 密码找回的安全设计思路

195页

1. 输入用户名、手机、邮箱阶段：存在完全或者部分显示隐私信息；或者服务器没有严格验证，依靠客户端提交的数据。
2. 添加验证码和新密码阶段：验证凭证简单，可能暴力破解；没有限定次数；Token验证可以预测（机器伪造爆破）；凭证在源代码中。
3. 发送密码阶段：凭证和用户间关系没有严格验证

基本思路

- 接收验证码的邮箱和手机号不可由用户控制，直接从数据库中读取。
- 加强验证凭证复杂度，防止被暴力破解。
- 限制验证凭证错误次数验证凭证设置失效时间。
- 验证凭证不要保存在页面。输入用户邮箱或ID、手机号取验证凭证的地方需要设置验证码防止短信炸弹和批量找回等。
- 验证凭证跟用户名、用户ID、用户邮箱绑定，找回密码时验证当前凭证是否是当前用户的。

## 1.2. 资料查看与修改的安全设计思路

197页的案例。背景知识：[HTTP、Cookie、Session](../工具/http.md)

- 用户资源ID （订单ID、地址ID等等）绑定到用户，只允许有权限的用户查看。
- 当前用户信息存储到session,不放到request中，避免攻击者修改当前用户ID

## 1.3. 投票/积分/抽奖的安全设计思路

199页案例。

- 机器识别码验证，每台机器都可以根据硬件信息生成唯一的识别码。
- 操作需要登录，当前用户信息从session中读取。

## 1.4. 充值支付的安全设计思路

- 保证数据可信，商品单价及总价不可从客户端获取
- 购买数量不能小于等于0,<65536。
- 账户支付锁定机制，当一个支付操作开始就应该立马锁定当前账户，不能同时两个后端请求对余额进行操作

## 1.5. 私信及反馈的安全设计思路

201页案例，利用XSS漏洞获取管理员cookie。

- 将特殊字符进行过滤
- 使用白名单和黑名单结合的方式。

## 1.6. 远程地址访问的安全设计思路

- 限制填写内网地址
- 考虑短地址的问题

## 1.7. 文件管理的安全设计思路

- 禁止写入脚本可在服务器端执行的文件
- 限制文件管理功能操作的目录
- 限制文件管理功能访问权限
- 禁止上传特殊字符文件名的文件

## 1.8. 数据库管理的安全设计思路

- 限制可以操作的数据库表，如果是数据库备份可以直接在代码里面写死只能操作哪些表，如果是执行SQL语句的方式可以另建一个MySQL用户，限制可以操作的表和字段。
- 限制备份到服务器上的文件名，需要系统随机生成类似md5并且长度不能低于16位，扩展名不能自定义

## 1.9. 命令/代码执行的安全设计思路

- 严格控制该功能访问权限，建议高权限才能访问。
- 在满足业务需求的情况下，可以设置命令白名单，可使用escapeshellcmd()以 及escapeshellarg()函数进行过滤，命令直接写死在代码中更好。
- 给命令及代码执行功能设置独立密码。
- 代码执行功能限制脚本可访问的路径。
- 在满足需求的情况下限制当前执行命令的系统用户权限。

## 1.10. 文件/数据库备份的安全设计思路

207页解释。

- 进行权限控制，由于备份功能是一个非常高危敏感的功能，一定要限制高权限才能使用。
- 文件名随机生成，不可预测，可以把当前时间戳加上6位以上字母和数字随机生成的字符串进行md5来做为文件名。

## 1.11. API的安全设计思路

- 访问权限控制
- 防止敏感信息泄露
- SQL注入等常规漏洞