1.应用场景
| 主要用于接口安全. |
2.学习/操作
|
对外接口安全措施的作用主要体现在两个方面，一方面是如何保证数据在传输过程中的安全性，另一方面是数据已经到达服务器端，服务器端如何识别数据，如何不被攻击。此前，一位网名为 ksfzhaohui 的高级程序员在开源中国社区分享了一些常用的安全措施以及实现方法，希望给广大开发者参考。
1. 数据加密 数据在传输过程中是很容易被抓包的，如果直接传输，数据可以被任何人获取，所以必须对数据加密。加密方式有对称加密和非对称加密：对称加密：对称密钥在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有 DES、AES。优点是计算速度快，缺点是在数据传送前，发送方和接收方必须商定好密钥，并完好保存。如果一方的密钥被泄露，那么加密信息也就不安全了；非对称加密：服务端会生成一对密钥，私钥存放在服务器端，公钥可以发布给任何人使用。与对称加密相比，这种方式更安全，但速度慢太多了。现在主流的做法是使用 HTTPS 协议，在 HTTP 和 TCP 之间添加一层加密层 (SSL 层)，这一层负责数据的加密和解密。HTTPS 的实现方式结合了对称加密与非对称加密的优点，在安全和性能方面都比较突出。
2. 数据加签 数据加签就是由发送者产生一段无法伪造的数字串，来保证数据在传输过程中不被篡改。数据如果已经通过 HTTPS 加密了，其加密部分只是在外网，而加签可以防止内网中数据被篡改。数据签名使用较多的是 MD5 算法，将需要提交的数据通过某种方式组合，然后通过 MD5 生成一段加密字符串，这段加密字符串就是数据包的签名。而其中的用户密钥，客户端和服务端都保留一份，会更加安全。
3. 时间戳机制 数据经过如上的加密、加签处理后，就算被抓包也不能看到真实的数据。但是有的不法者不关心真实数据，而是直接拿到抓取的数据包进行恶意请求。这时可以使用时间戳机制，在每次请求中加入当前的时间，服务器端会拿到当前时间与消息中的时间相减，看看是否在一个固定的时间范围内，比如 5 分钟，这样恶意请求的数据包是无法更改时间的，所以 5 分钟后就视为非法请求了。
4. AppID 机制 大部分网站都需要用户名和密码才能登录，这其实也是一种安全机制。相应的对外接口也需要这么一种机制，使用接口的用户需要在后台开通 AppID，提供给用户相关的密钥。在调用的接口中需要提供 AppID+ 密钥，服务器端会进行相关的验证。生成唯一的 AppID 即可，根据实际情况看是否需要全局唯一，同时密钥使用字母、数字等特殊字符随机生成。
5. 限流机制 本来就是真实的用户，并且开通了 AppID，但出现了频繁调用接口的情况，这时需要给相关 AppID 限流处理，常用的限流算法包括：令牌桶限流、漏桶限流、计数器限流。令牌桶算法的原理是系统以一定速率向桶中放入令牌，填满了就丢弃令牌。请求来时会先从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌。漏桶算法的原理是按照固定常量速率流出请求，流入请求速率任意，当请求数超过桶的容量时，新的请求等待或者拒绝服务，漏桶算法可以强制限制数据的传输速度。计数器算法比较简单粗暴，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数。计数器限流只要一定时间内的总请求数超过设定的阀值，就会进行限流。
6. 黑名单机制 如果一个 AppID 进行过很多非法操作，或者专门有一个中黑系统，经过分析之后可以直接将此 AppID 列入黑名单，所有请求直接返回错误码。如何查看黑名单列表呢？可以给用户设置一个状态比如：初始化状态、正常状态、中黑状态、关闭状态等等。或者直接通过分布式配置中心，保存黑名单列表，每次检查用户是否在列表中即可。
7. 数据合法性校验 这是每个系统都会有的处理机制，只有在数据合法的情况下才会进行数据处理。每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证号码长度和组成、电话号码长度和组成等等。合法性校验包括常规性校验以及业务校验，前者包括签名校验、必填校验、长度校验、类型校验、格式校验等，后者根据实际业务而定，比如订单金额不能小于 0 等等。
以上就是几种常见的安全措施机制，也欢迎你在评论区补充其他方式. |
3.问题/补充
|
1.WiFi是什么, 有绝对安全的WiFi吗? TBD
2.如何取得路由器的管理员密码? TBD
3.如何避免在网络中暴露的位置信息 TBD |
4.参考
|
https://time.geekbang.org/column/article/224701 //如何设计一个安全的对外接口？ https://blog.csdn.net/william_n/article/details/103453284 //接口鉴权 |
后续补充
...