已解決430363個問題，去搜搜看，總會有你想問的

REST身份驗證方案的安全性

首頁猿問 REST身份驗證方案的安全性

REST身份驗證方案的安全性

安全

幕布斯6054654 2019-12-07 13:39:45

背景：我正在為REST Web服務設計身份驗證方案。這并不是“真正”需要安全的（它更多是一個個人項目），但我想使其與練習/學習經驗一樣安全。我不想使用SSL，因為我不想麻煩，而且在大多數情況下也不需要設置它的開銷。這些SO問題對于我入門特別有用：RESTful身份驗證保護REST API / Web服務的最佳做法最佳SOAP / REST / RPC Web API的示例？你為什么喜歡他們？那他們怎么了？我正在考慮使用Amazon S3身份驗證的簡化版本（我喜歡OAuth，但對于我的需求而言似乎太復雜了）。我在請求中添加了服務器提供的隨機生成的隨機數，以防止重放攻擊。要解決這個問題：S3和OAuth都依賴于對請求URL以及一些選定的標頭進行簽名。他們都沒有在 POST或PUT請求的請求主體上簽名。這難道不容易受到中間人攻擊，這種中間人攻擊會保留url和標頭并用攻擊者想要的任何數據替換請求正文？似乎我可以通過在已簽名的字符串中包含請求正文的哈希值來預防這種情況。這樣安全嗎？

查看完整描述

3 回答

慕桂英4014372

TA貢獻1871條經驗獲得超13個贊

先前的答案僅在數據傳輸的上下文中提到了SSL，實際上并未涵蓋身份驗證。

您真的在問有關安全認證REST API客戶端的問題。除非您使用TLS客戶端身份驗證，否則單獨使用SSL 并不是REST API可行的身份驗證機制。沒有客戶端身份驗證的SSL僅對服務器進行身份驗證，這與大多數REST API無關，因為您確實要對客戶端進行身份驗證。

如果您不使用TLS客戶端身份驗證，則需要使用基于摘要的身份驗證方案（例如Amazon Web Service的自定義方案）或OAuth 1.0a甚至HTTP Basic身份驗證（但僅通過SSL）。

這些方案驗證請求是由預期的人發送的。TLS（SSL）（無客戶端身份驗證）可確保通過網絡發送的數據保持不受干擾。它們是分開的，但又是互補的。

對于那些感興趣的人，我擴展了一個關于HTTP身份驗證方案及其工作原理的SO問題。

反對回復 2019-12-07

狐的傳說

TA貢獻1804條經驗獲得超3個贊

REST意味著使用Web標準，而Web上“安全”傳輸的標準是SSL。其他任何事情都會變得很時髦，并且需要為客戶端進行額外的部署工作，這將必須具有可用的加密庫。

原則上，一旦您提交SSL，實際上就不需要花哨的時間了。您可以再次使用Web標準并使用HTTP Basic auth（隨每個請求一起發送的用戶名和秘密令牌），因為它比精心設計的簽名協議要簡單得多，并且在安全連接的情況下仍然有效。您只需要確保密碼永遠不會覆蓋純文本即可。因此，如果曾經通過純文本連接收到密碼，則您甚至可能會禁用密碼并向開發人員發送郵件。您還應該確保憑據在收到后不會記錄在任何地方，就像您不會記錄常規密碼一樣。

HTTP摘要是一種更安全的方法，因為它可以防止傳遞秘密令牌。而是服務器可以在另一端驗證的哈希值。如果您已采取上述預防措施，對于不太敏感的應用程序可能會顯得過高。畢竟，用戶的密碼已經在他們登錄時以純文本格式傳輸（除非您在瀏覽器中進行了一些精美的JavaScript加密），并且同樣在每次請求時都存儲了他們的cookie。

請注意，使用API，客戶端最好傳遞令牌-隨機生成的字符串-而不是開發人員使用其登錄網站的密碼。因此，開發人員應該能夠登錄到您的站點并生成可用于API驗證的新令牌。

使用令牌的主要原因是，如果令牌被泄露，可以將其替換，而如果密碼被泄露，則所有者可以登錄到開發者的帳戶，并對其進行任何操作。令牌的另一個優點是您可以向同一開發人員發行多個令牌。也許是因為他們擁有多個應用程序，或者是因為他們想要具有不同訪問級別的令牌。

（已更新，以涵蓋僅使用SSL進行連接的含義。）

反對回復 2019-12-07

3 回答
0 關注
556 瀏覽

關注

添加回答

舉報

0/150

提交

取消

亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

熱搜

最近搜索清空

REST身份驗證方案的安全性

REST身份驗證方案的安全性

3 回答

添加回答