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頭裏

記得關注我呦