0x01 前言
目前，大部分的业务系统需要提供公网域名、IP进行访问，若涉及用户个人信息、支付交易、订单信息等有关接口，那么接口的安全性就相当重要了。
0x02 安全需求
在设计、建模初期主要思考下列两个方面的问题：
- 如何保证数据在传输过程中的安全性？
- 数据在到达服务端后，服务端如何识别数据，如何不被攻击？
0x03 安全方案
3.1 数据加密
我们都知道数据在传输的过程中是很容易被中间人劫持抓包的，如果直接传输比如通过http协议，那么用户传输的数据可以被任何人获取。
所以必须对数据加密，常见的做法有：
- 对关键字段加密比如密码通过md5等手段处理；
- 使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密；
3.2 数据签名
数据签名是指由客户端根据发送的数据包参数、数据等，产生一段无法伪造的一段字符串，到达服务端后经服务端进行解析处理，以此来保证数据在传输过程中不被篡改。
注：
这里特殊提一下，好多人有疑问：“不是说https就对数据进行了加密了嘛？使用了ssl就可以保证传输过程的安全性了嘛？”
数据包通过TLS/SSL加密后，理论上就算被抓包，也无法对数据进行篡改。但是我们要知道加密的部分其实只是在客户端和服务端的数据传输过程中，也就是说客户端和服务端是直接交互的，假如客户端在本地安装了某个中间人代理的证书，那么客户端与服务端的通信就变成了“客户端->代理服务器”->“代理服务器->服务端”两段HTTPS通道，然后中间人代理获得Client消息后先解密后再重新加密，然后代替客户端发给服务端，这样中间代理服务器就能劫持、篡改数据包了。
3.3 时间戳机制
数据包在经过数据签名时通常需要添加一个随机值来保证数据包的唯一性，随机值通常采用当前时间的时间戳。
在每次HTTP请求，都加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则大致可以认为是非法的请求。
一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以，此时请求中的timestamp参数已经失效了。如果黑客修改timestamp参数为当前的时间戳，则signature参数对应的数字签名就会失效，因为黑客不知道签名秘钥，没有办法生成新的数字签名。
3.4 AppID校验
对于部分业务功能来说，并不是谁都能使用的，大部分网站基本都需要用户名和密码才能登录，这是一种有效的验证请求合法性的安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通appid，提供给用户相关的密钥；在调用的接口中需要提供appid+密钥，服务器端会进行相关的验证。
3.5 限流机制
如果商户的appid和密码泄漏，被恶意用户非法利用，就有可能出现频繁调用接口的情况；这种情况需要给相关appid做限流处理，常用的限流算法有令牌桶和漏桶算法。
3.6 黑名单机制
如果此appid进行过很多非法操作，经过分析之后直接将此appid列入黑名单，所有请求直接返回错误码。
3.7 数据合法性校验
数据合法性校验是每个系统都会有的校验、处理机制，只有在数据是合法的情况下才会进行数据处理。
每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如参数的长度、参数的类型，参数的业务场景合法性等。
0x04 安全建设
本文为我在甲方安全建设中所做的一部分，为了方便研发同学快速了解漏洞原理、业务场景、漏洞修复方法等，在互联网上搜索及自己整理的一个漏洞知识库文档中的一节，点击阅读原文即可查看全部文档。
文档中内容均为手打及互联网收集，如有侵权请与我联系删除
