開發安全的 API 所須要覈對的清單

如下是當你在設計, 測試以及發佈你的 API 的時候所須要覈對的重要安全措施。

身份認證

• 不要使用 Basic Auth 使用標準的認證協議 (如 JWT, OAuth).
• 不要再造 Authentication, token generating, password storing 這些輪子, 使用標準的.
• 在登陸中使用 Max Retry 和自動封禁功能.
• 加密全部的敏感數據.

JWT (JSON Web Token)

• 使用隨機複雜的密鑰 (JWT Secret) 以增長暴力破解的難度.
• 不要在請求體中直接提取數據, 要對數據進行加密 (HS256 或 RS256).
• 使 token 的過時時間儘可能的短 (TTL, RTTL).
• 不要在 JWT 的請求體中存放敏感數據, 它是可破解的.

OAuth 受權或認證協議

• 始終在後臺驗證 redirect_uri, 只容許白名單的 URL.
• 每次交換令牌的時候不要加 token (不容許 response_type=token).
• 使用 state 參數並填充隨機的哈希數來防止跨站請求僞造(CSRF).
• 對不一樣的應用分別定義默認的做用域和各自有效的做用域參數.

訪問

• 限制流量來防止 DDoS 攻擊和暴力攻擊.
• 在服務端使用 HTTPS 協議來防止 MITM 攻擊.
• 使用 HSTS 協議防止 SSLStrip 攻擊.

過濾輸入

• 使用與操做相符的 HTTP 操做函數, GET (讀取), POST (建立), PUT (替換/更新) 以及 DELETE (刪除記錄), 若是請求的方法不適用於請求的資源則返回 405 Method Not Allowed.
• 在請求頭中的 content-type 字段使用內容驗證來只容許支持的格式 (如 application/xml, application/json 等等) 並在不知足條件的時候返回 406 Not Acceptable.
• 驗證 content-type 的發佈數據和你收到的同樣 (如 application/x-www-form-urlencoded, multipart/form-data, application/json 等等).
• 驗證用戶輸入來避免一些普通的易受攻擊缺陷 (如 XSS, SQL-注入, 遠程代碼執行 等等).
• 不要在 URL 中使用任何敏感的數據 (credentials, Passwords, security tokens, or API keys), 而是使用標準的認證請求頭.
• 使用一個 API Gateway 服務來啓用緩存、訪問速率限制 (如 Quota, Spike Arrest, Concurrent Rate Limit) 以及動態地部署 APIs resources.

處理

• 檢查是否全部的終端都在身份認證以後, 以免被破壞了的認證體系.
• 避免使用特有的資源 id. 使用 /me/orders 替代 /user/654321/orders
• 使用 UUID 代替自增加的 id.
• 若是須要解析 XML 文件, 確保實體解析(entity parsing)是關閉的以免 XXE 攻擊.
• 若是須要解析 XML 文件, 確保實體擴展(entity expansion)是關閉的以免經過指數實體擴展攻擊實現的 Billion Laughs/XML bomb.
• 在文件上傳中使用 CDN.
• 若是須要處理大量的數據, 使用 Workers 和 Queues 來快速響應, 從而避免 HTTP 阻塞.
• 不要忘了把 DEBUG 模式關掉.

輸出

• 發送 X-Content-Type-Options: nosniff 頭.
• 發送 X-Frame-Options: deny 頭.
• 發送 Content-Security-Policy: default-src 'none' 頭.
• 刪除指紋頭 - X-Powered-By, Server, X-AspNet-Version 等等.
• 在響應中強制使用 content-type, 若是你的類型是 application/json 那麼你的 content-type 就是 application/json.
• 不要返回敏感的數據, 如 credentials, Passwords, security tokens.
• 在操做結束時返回恰當的狀態碼. (如 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed 等等).

持續集成和持續部署

• 使用單元測試和集成測試來審計你的設計和實現.
• 引入代碼審查流程, 不要自行批准更改.
• 在推送到生產環境以前確保服務的全部組件都用殺毒軟件靜態地掃描過, 包括第三方庫和其它依賴.
• 爲部署設計一個回滾方案.

權限系統 (註冊/註冊/二次驗證/密碼重置)

• 任何地方都使用 HTTPS.
• 使用 Bcrypt 存儲密碼哈希 (沒有使用鹽的必要 - Bcrypt 乾的就是這個事).
• 登出以後銷燬會話 ID .
• 密碼重置後銷燬全部活躍的會話.
• OAuth2 驗證必須包含 state 參數.
• 登錄成功以後不能直接重定向到開放的路徑（須要校驗，不然容易存在釣魚攻擊）.
• 當解析用戶註冊/登錄的輸入時，過濾 javascript://、 data:// 以及其餘 CRLF 字符.
• 使用 secure/httpOnly cookies.
• 移動端使用 OTP 驗證時，當調用 generate OTP 或者 Resend OTP API 時不能把 OTP（One Time Password） 直接返回。（通常是經過發送手機驗證短信，郵箱隨機 code 等方式，而不是直接 response）
• 限制單個用戶 Login、Verify OTP、 Resend OTP、generate OTP 等 API 的調用次數，使用 Captcha 等手段防止暴力破解.
• 檢查郵件或短信裏的重置密碼的 token，確保隨機性（沒法猜想）
• 給重置密碼的 token 設置過時時間.
• 重置密碼成功後，將重置使用的 token 失效.

用戶數據和權限校驗

• 諸如個人購物車、個人瀏覽歷史之類的資源訪問，必須檢查當前登陸的用戶是否有這些資源的訪問權限.
• 避免資源 ID 被連續遍歷訪問，使用 /me/orders 代替 /user/37153/orders 以防你忘了檢查權限，致使數據泄露。
• 修改郵箱/手機號碼功能必須首先確認用戶已經驗證過郵箱/手機是他本身的。
• 任何上傳功能應該過濾用戶上傳的文件名，另外，爲了普適性的緣由（而不是安全問題），上傳的東西應該存放到例如 S3 之類的雲存儲上面(用 lambda 處理)，而不是存儲在本身的服務器，防止代碼執行。
• 我的頭像上傳 功能應該過濾全部的 EXIF 標籤，即使沒有這個需求.
• 用戶 ID 或者其餘的 ID，應該使用 RFC compliant 的 UUID 而不是整數. 你能夠從 github 找到你所用的語言的實現.
• JWT（JSON Web Token）很棒.當你須要構建一個 單頁應用/API 時使用.

安卓和 iOS APP

• 支付網關的 鹽（salt） 不該該被硬編碼
• 來自第三方的 secret 和 auth token 不該該被硬編碼
• 在服務器之間調用的 API 不該該在 app 裏面調用
• 在安卓系統下，要當心評估全部申請的 權限
• 在 iOS 系統下，使用系統的鑰匙串來存儲敏感信息（權限 token、api key、 等等） 不要 把這類信息存儲在用戶配置裏面
• 強烈推薦證書綁定（Certificate pinning）

操做

• 若是你的業務很小或者你缺少經驗，能夠評估一下使用 AWS 或者一個 PaaS 平臺來運行代碼
• 在雲上使用正規的腳本建立虛擬機
• 檢查全部機器沒有必要開放的端口
• 檢查數據庫是否沒有設置密碼或者使用默認密碼，特別是 MongoDB 和 Redis
• 使用 SSH 登陸你的機器，不要使用密碼，而是經過 SSH key 驗證來登陸
• 及時更新系統，防止出現 0day 漏洞，好比 Heartbleed、Shellshock 等
• 修改服務器配置，HTTPS 使用 TLS1.2，禁用其餘的模式。(值得這麼作)
• 不要在線上開啓 DEBUG 模式，有些框架，DEBUG 模式會開啓不少權限以及後門，或者是暴露一些敏感數據到錯誤棧信息裏面
• 對壞人和 DDOS 攻擊要有所準備，使用那些提供 DDOS 清洗的主機服務
• 監控你的系統，同時記錄到日誌裏面 (例如使用 New Relic 或者其餘 ).
• 若是是 2B 的業務，堅持順從需求。若是使用 AWS S3,能夠考慮使用 數據加密 功能. 若是使用 AWS EC2，考慮使用磁盤加密功能（如今系統啓動盤也能加密了）

關於人

• 開一個郵件組（例如：security@coolcorp.io）和蒐集頁面，方便安全研究人員提交漏洞
• 取決於你的業務，限制用戶數據庫的訪問
• 對報告 bug、漏洞的人有禮貌
• 把你的代碼給那些有安全編碼觀念的同伴進行 review (More eyes)
• 被黑或者數據泄露時，檢查數據訪問前的日誌，通知用戶更改密碼。你可能須要外部的機構來幫助審計
• 使用 Netflix Scumblr 及時瞭解你的組織（公司）在社交網絡或者搜索引擎上的一些討論信息，好比黑客攻擊、漏洞等等

出處 Hack-with-Github/Awesome-Hacking Fallible