HTTP API 设计入坑指南（二）

时间 2019-11-09

标签 http api 设计指南栏目 HTTP/TCP 繁體版

原文原文链接

1、受权

参考文献：https://blog.risingstack.com/...php

1. Basic authentication (最简单，适用于没有第三方的请求接口中)

客户端发送authorization，内容为 Basic Base64编码(username:password)，用户名和密码没有加密html

缺点：每一个请求都要带用户名和密码，不安全laravel

2. Cookies

Session：用户登陆成功，服务端返回一个sessionID，客户端将其存在cookie中，每次请求都会带这个sessionIDweb

HTTP Only：(config/session.php中设置)若是是true，JS代码将没法读取cookie信息，拿不到document.cookies。从而防止XSS攻击，增长了cookie的安全性，但即使如此，也不要将重要信息存入cookie算法

3. Single Key ：双方约定惟一标示

4. Tokens

4.1 JWT:Json Web Token

参考文献：https://www.jianshu.com/p/af8...;
用户完成登陆以后，每一个请求都会包含JWT，用来验证用户身份和访问权限数据库

构成:json

Header头部包括Token类型和加密算法，并base64加密
Payload负载存放有效信息，并base64加密
Signature签名包括Header、Payload、Secret秘钥（Secret保存在服务端的，服务端会根据这个密钥进行生成token和验证，因此须要保护好）

三部分用.链接，生成完整的tokenapi

cookie+session一般是保存在内存中，并且服务从单服务到多服务会面临的session共享问题，随着用户量的增多，开销就会越大。而JWT只须要服务端生成token，客户端保存token，每次请求在头部authorization中使用Bearer携带token，服务端认证解析就可。跨域

由于JWT不使用cookie，因此支持跨域浏览器

由于json的通用性，因此支持跨语言

4.2 Self-Tokens

根据业务，本身写生成token的逻辑，注意设定请求次数和过时时间

5. Signatures

API的使用者和提供者拥有一样的私钥，才能操做业务

算法以下：
对参数进行字典升序排列，防止顺序不一样，生成的签名不一样
排序后进行字符串链接
app-secret为后缀，进行加密，再转大写

案例:

6. One-Time Passwords（OTP）一次性密码

Time-based One-time Password Algorithm 基于时间
HMAC-based One-time Password Algorithm 基于计数器

感受QQ安全中心就是这个原理，更多内容参考

7. Oauth2

Oauth2至关于第三方，在客户端和服务端之间多设置了一层，用户给客户端受权，客户端向第三方认证申请token，申请成功后使用token向服务端申请资源

参考文献：

2、安全

1. 请求

不信任任何输入数据
校验数据格式：len,range,format,type
拒绝无效、非法内容
使用通用校验类库，不要本身造轮子
拒绝过大请求数据
记录失败次数，黑名单
验证码：清理session
登陆时访问一个脚本文件，用来生成验证码，将值保存在Session中，提交时判断输入值与session是否一致。若是缓存不清理，验证码就会一直有效，不安全。
保存时能够用session::flash，访问一次以后就会被删除，解决清理缓存的问题

2. 超范围读取数据 =》逻辑错误

3. 异常信息 =》敏感信息

4. 频率

X-RateLimit-Limit
X-RateLimit-Remaining
Retry-After
X-RateLimit-Reset

5. 安全链接（禁止跳过验证）=》HTTPS

HTTP：最广泛的一种网络协议，以明文方式发送内容，不适合传输一些敏感信息

HTTPS：HTTP的安全版，在HTTP基础上加了SSL协议，SSL依靠证书验证服务器身份，为客户端和服务端的通讯加密
做用一：创建数据传输的安全通道
做用二：确认网站的真实性
缺点：费用高，速度慢，流量成本大

区别：

HTTPS须要申请证书、
HTTPS数据加密，安全性高、
HTTP端口是80，HTTPS是443

6. 数据RSA加密

支付场景 https://docs.open.alipay.com/...

7. XSS

参考文献：http://laravelacademy.org/pos...
注入恶意JS代码,解决方案是用 htmlentities()转义数据

laravel的blade模板引擎已经帮咱们处理好了

{!!$data !!} 会原生输出HTML，适用于图片、连接
{{ $data  }} 会对数据进行转义，从而避免XSS攻击。

若是须要更强大的过滤HTML功能，可使用HTML Purifier库

8. SQL注入

注入恶意SQL语句，不只能get注入、post注入、还能cookie注入或利用PHP注释打碎关键词重组，解决方案以下：

伪静态：重写URL，隐藏传递的参数
关键词过滤：阻止恶意参数的输入，过滤掉敏感关键词和符号，利用正则过滤更好
SQL语言预处理：相似于一种编译过的要执行的SQL语句模板，它的优势是语句屡次执行，只作一次查询，减小时间，少占用资源，效率高

现代PHP框架不少都采用MVC模式，数据库的操做都依附于Model，底层已经作好了预防SQL注入

9. CORS 跨域资源共享

我写的《HTTP API 设计入坑指南一》里写跨域的时候提到过

10. CSRF

参考文献：

跨站域请求伪造，经过请求盗取用户cookie信息，解决策略以下：

验证HTTP Referer字段：Header里的referer字段用来记录请求的来源地址，黑客经过本身的网站去请求，地址不合法，拒绝请求。可是有些浏览器能够篡改referer值
token验证：既然黑客盗取了cookie信息，那就以参数形式加入随机的token，在服务器验证token
HTTP Header中自定义属性验证：和token同样，只是不放在参数中，而是Header头里

记得关注我呦