|
|
|
|
@ -1,7 +1,21 @@
|
|
|
|
|
- 要打造安全的应用程序，要从业务功能的设计开始
|
|
|
|
|
- 验证码、用户登录、用户注册、密码找回、资料操作、投票、积分、抽奖、充值支付、私信反馈、文件管理、 数据库管理以及命令执行等功能容易出现安全问题
|
|
|
|
|
|
|
|
|
|
# 验证码
|
|
|
|
|
- [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%以上的验证码是存在可以爆破和简单识别的问题，设计一个有效的验证码尤为重要
|
|
|
|
|
@ -36,9 +50,9 @@
|
|
|
|
|
4. 短信或者邮件验证码必须要6位以上字母和数字混合，图片或者语音验证码要加强混淆干扰，比如图片文字变形，增加干扰斑点等。语音验证码增加背景噪声。
|
|
|
|
|
5. 验证码要动态生成，不能统一生成多次调用
|
|
|
|
|
|
|
|
|
|
## 用户登录
|
|
|
|
|
## 1.1. 用户登录
|
|
|
|
|
|
|
|
|
|
### 撞库漏洞
|
|
|
|
|
### 1.1.1. 撞库漏洞
|
|
|
|
|
|
|
|
|
|
撞库漏洞是指登录口没有做登录次数限制，导致可以使用不同的用户及密码进行不断的登录尝试，以遍历用户密码；也可以理解为登录爆破。
|
|
|
|
|
|
|
|
|
|
@ -47,7 +61,7 @@
|
|
|
|
|
- 单时间段内IP登录错误次数限制
|
|
|
|
|
- 针对撞库漏洞比较好的解决方案是使用登录验证码和多因素认证
|
|
|
|
|
|
|
|
|
|
### API 登录
|
|
|
|
|
### 1.1.2. API 登录
|
|
|
|
|
|
|
|
|
|
- 登录密钥(clientkey)需要不可预测并且不固定，生成key的算法中加入随机字符。
|
|
|
|
|
- API接口禁止搜索引擎收录。
|
|
|
|
|
@ -55,7 +69,7 @@
|
|
|
|
|
|
|
|
|
|
案例：193页
|
|
|
|
|
|
|
|
|
|
### 用户注册
|
|
|
|
|
### 1.1.3. 用户注册
|
|
|
|
|
|
|
|
|
|
垃圾注册，机器注册是比较头痛的问题。如何抵御恶意注册？
|
|
|
|
|
|
|
|
|
|
@ -65,7 +79,7 @@
|
|
|
|
|
4. 根据账号格式自学习识别垃圾账号
|
|
|
|
|
5. 防止SQL注入漏洞与XSS漏洞
|
|
|
|
|
|
|
|
|
|
### 密码找回的安全设计思路
|
|
|
|
|
### 1.1.4. 密码找回的安全设计思路
|
|
|
|
|
|
|
|
|
|
195页
|
|
|
|
|
|
|
|
|
|
@ -81,4 +95,67 @@
|
|
|
|
|
- 验证凭证不要保存在页面。输入用户邮箱或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注入等常规漏洞
|
