僅僅使用HTTPS來保護API RESTful Web應用程序？

我正在研究一個新的Web應用程序，我想用HATEOAS，RESTful原則開發。我正在研究身份驗證方案，並且用於驗證Web應用程序的信息（通過瀏覽器，而不是機器到機器）似乎有點欠缺。僅僅使用HTTPS來保護API RESTful Web應用程序？

在建立HTTPS會話和初始登錄之後，似乎沒有任何需要傳遞令牌，cookie，HMAC，隨機數等的需求。基本認證或HMAC，OAuth等似乎也不重要：HTTPS會話是安全的。

我可能錯過了一些東西。以下是我想象我的解決方案的工作： -

用戶導航到Web應用程序的登錄頁面（HTTPS：//acme.com/login）
用戶指定的用戶名和密碼，
網絡服務驗證用戶名和密碼：授權的資源

允許訪問對於服務器，以確定在後續請求，這既可以通過驗證的用戶： -

傳遞明文用戶名作爲標題或餅乾 - 這是REST風格，IMO
使用SSL會話ID（如果可用的框架），查找用戶。這不像會話ID需要存儲的那樣RESTful

我看不出有什麼理由使用HTTPS以外的任何其他功能。我錯過了什麼，漏洞或功能缺失？

謝謝！

來源

2014-03-26 David Kerr

您必須在此處定義安全性。 SSL是相當安全的（儘管最近OpenSSL/Heartbleed存在問題）。

但是，正如我所看到的，您使用的是用戶名和密碼/登錄名，爲何不將HTTP Basic和HTTPS結合使用？大多數框架都支持基本身份驗證，所以。每次打電話時都簡單地驗證用戶身份。這是使用身份驗證進行RESTFULL的唯一方法，因爲您希望成爲無狀態的。

來源

2014-05-13 16:50:37 Zerkz

我已經發展了我的「架構」，現在我正在考慮讓我的應用程序成爲服務器驅動的客戶端（瀏覽器）漸進式增強功能。它仍然是RESTful，可以從其他類型的客戶端（JSON/XML/HTML表示）驅動。但我如何使用Basic或Digest Auth進行LOGGING OFF？我可以輕鬆地使用自定義客戶端，但如何通過瀏覽器？ –

我的猜測是你可以刪除基本的Auth頭。除了基本前提，我還不是100％熟悉摘要。 – Zerkz

對於大多數REST API，HTTP基本認證（即用戶名和密碼）+ HTTPS通常被認爲足夠安全，特別是對於內部使用。但是，如果沒有唯一的隨機數（或事務ID），您很容易受到重播攻擊。

例如，想象一下攻擊者能夠記錄一個真正的PUT請求，以便在數據庫中創建一些新記錄。然後，他們可以在一個循環中重播該消息，通過填充數據庫表在您的API上啓動DoS攻擊。儘管郵件是通過SSL進行加密的，但它仍然包含有效的憑證，因此來自攻擊者的每個重播請求都將被您的API完全解密併成功進行身份驗證。

HTTP摘要式身份驗證包含隨每個請求而變化的隨機數，因此被認爲是更安全的選項。

來源

2014-05-15 05:25:51

+1通過摘要認證進行重放攻擊和克服。 –

我認爲HTTPS實際上可以防止重播攻擊..請參閱http://serverfault.com/questions/32473/does-https-include-protection-from-a-replay-attack和http://security.stackexchange.com/問題/ 20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks – Daniel

@Daniel是的，你是對的 - 通常。不過，我注意到對這些答案的評論留下了一些疑問。我的結論是，HTTPS標準應該防止重放攻擊，但該標準的某些*實現*可能不會。 –

僅僅使用HTTPS來保護API RESTful Web應用程序？

回答

相關問題