保護REST API/Web服務的最佳實踐

在設計REST API或服務時，是否存在處理安全性(身份驗證，受權，身份管理)的最佳實踐？ 在構建SOAP API時，您可使用WS-Security做爲指導，有關該主題的文獻不少。我發現了有關保護REST端點的更少信息。 儘管我瞭解REST故意沒有相似於WS- *的規範，但我但願最佳實踐或推薦模式已經出現。 任何有關文件的討論或連接將很是感激。 若是它很重要，咱們將使用WCF和POX/JSON序列化消息來構建使用.NET Framework v3.5構建的REST API/Services。

Github上有一個很棒的清單： 的驗證

• 請勿使用Basic Auth使用標準認證(例如JWT，OAuth)。
• 不要在認證，代幣生成，密碼存儲中從新發明輪子。使用標準。
• 在登陸中使用Max Retry和jail功能。
• 在全部敏感數據上使用加密。
JWT(JSON Web令牌)
• 使用一個隨機的複雜鍵(JWT祕密)來讓暴力破解令牌變得很是困難。
• 不要從有效負載中提取算法。在後端強制執行算法(HS256或RS256)。
• 儘量縮短令牌到期時間(TTL，RTTL)。
• 不要在JWT有效載荷中存儲敏感數據，它能夠被輕鬆解碼。
的的OAuth
• 始終驗證redirect_uri服務器端是否只容許列入白名單的網址。
• 老是嘗試交換代碼而不是代幣(不容許response_type=token)。
• 使用狀態參數和隨機散列來防止OAuth身份驗證過程當中的CSRF。
• 定義默認範圍，併爲每一個應用程序驗證範圍參數。
使用
• 限制請求(Throttling)以免DDoS /強力攻擊。
• 在服務器端使用HTTPS以免MITM(中間人攻擊)
• 使用帶SSL的HSTS標頭來避免SSL Strip攻擊。
的輸入
• 根據操做使用適當的HTTP方法：GET(讀取)，POST(建立)，PUT/PATCH(替換/更新)和DELETE(刪除記錄)，若是請求的方法不是，則使用405 Method Not Allowed迴應適合請求的資源。
• 根據請求驗證內容類型Accept標題(內容協商)以僅容許您支持的格式(例如application/xml，application/json等)，並在406 Not Acceptable響應中迴應(若是不匹配)。
• 按照您接受的方式驗證發佈數據的content-type(例如，application/x-www-form-urlencoded，multipart/form-data，application/json等)。
• 驗證用戶輸入以免常見漏洞(例如XSS，SQL注入，遠程代碼執行等)。
• 請勿在網址中使用任何敏感數據(憑據，密碼，安全令牌或API密鑰)，但請使用標準的Authorization標頭。
• 使用API​​網關服務啓用緩存，Rate Limit策略(例如配額，尖峯捕捉，併發速率限制)以及動態部署API資源。
的處理
• 檢查全部端點是否在身份驗證後受到保護，以免身份驗證過程當中斷。
• 應該避免用戶本身的資源ID。使用/ me/orders而不是/ user/654321/orders。
• 不要自動增長ID。改成使用UUID。
• 若是您正在解析XML文件，請確保未啓用實體解析以免XXE(XML外部實體攻擊)。
• 若是您正在解析XML文件，請確保實體展開未啓用，以經過指數實體展開攻擊來避免十億笑/ XML炸彈。
• 使用CDN進行文件上傳。
• 若是您處理大量數據，請使用工做人員和隊列儘量在後臺進行處理，並快速返回響應以免HTTP阻止。
• 不要忘記關閉 DEBUG 模式。
的輸出
• 發送X-Content-Type-Options: nosniff標頭。
• 發送X-Frame-Options: deny標頭。
• 發送Content-Security-Policy: default-src'none'標頭。
• 移除指紋標頭 - X-Powered-By，Server，X-AspNet-Version等。
• 若是您返回application/json，那麼您的響應內容類型爲application/json。
• 強制content-type做爲迴應。
• 不要傳回密碼，密碼，安全令牌等敏感數據。
• 根據完成的操做返回正確的狀態碼。 (例如200 OK，400 Bad Request，401 Unauthorized，405 Method Not Allowed等)。

 

https://oomake.com/question/731