如何安全地將身份驗證傳輸到REST API？

Question

我們的web服務器實現了一個無狀態的JSON API（沒有登錄步驟）。到現在爲止，我們所有的端點已經POST - 只與包含在POST體認證信息：

POST /api/getData 
{ 
    "apiKey": "I5r8ccXa8BLgoO50iZpunOGyf0h5e28L1exNpV5m5LI" 
    "userId": "8A7tRggxWjyQ+grQIwkAswtaityHhtQm0NTFGD5wnmM=" 
    "passwordAuth": "p0/yv/Ptv8kOAY1k2NpR9EhwvGA/n/DF79JGaKJmF/k=" 
    "otpToken": "913012" 
} 

這是不是很REST-FUL，效果顯着。我們希望對我們的只讀請求使用HTTP GET請求，但這意味着以不同的方式發送身份驗證信息。有很多可能性：

• 把它的URI？
• 把它放在餅乾？
• 把它放在一個自定義的HTTP Authentication標題中？
• 發明我們自己的自定義HTTP頭文件嗎？

哪一個更好，爲什麼？或者，身體仍然是傳輸任意驗證信息最安全的方式？

客戶端是一個典型的手機應用程序，但我們可能會在一天內做一個瀏覽器版本。一切都通過HTTPS運行。密碼哈希和其他加密的東西在客戶端上運行（我們的應用程序進行端到端加密）。

Answer 1

所有五個選項的基本工作原理，但他們各自提出自己的權衡：

• 的URI經常在日誌中結束。如果URI包含任何敏感信息，您將不得不清理服務器日誌或將它們與您的密碼數據庫進行相同級別的安全處理。兩個選項都很糟糕。
• 瀏覽器會根據每個請求自動發送cookie。如果攻擊者可以欺騙用戶訪問像your-app.com/resetpassword這樣的URI（例如，通過將其放入<img>標記中），則該請求將被完全驗證。攻擊者甚至不需要知道憑據是這個工作。這被稱爲CSRF錯誤。
• 自定義Authentication協議確實被HTTP規範允許，但許多框架都是針對標準機制的。如果你走這條路，你最終可能會與自己的工具作鬥爭，以使事情順利進行。
• 自定義標頭通常可用。許多CSRF保護技術依賴自定義標頭，如X-Csrf-Token來實現，並且沒有任何廣泛的兼容性問題。

鑑於所有這些，自定義HTTP頭可能是您的應用程序的方式。