安全：通過api處理兩個應用程序

Question

我有2個應用程序。第一個應用程序（A）具有客戶端（HTML）和服務器端（RUBY，PHP或其他）。第二個應用程序（B）是一個API。一切都通過https。考慮這種情況：

1. 用戶類型的電子郵件和密碼在登錄框（附錄A，客戶端），然後單擊「確定」
2. 應用A（服務器端）檢查CSRF令牌和發送電子郵件和密碼發送到API（App B）使用特定於API的HTTP憑證（僅知道服務器端）
3. 應用程序B檢查API憑證，然後檢查用戶憑證（電子郵件和密碼）
4. 應用程序B回答所有內容對應用程序A ）
5. 應用程序爲用戶創建會話，他可以知道使用該應用程序。有時候App A（服務器端）會調用App B來提問。

那麼它足夠安全嗎？它是愚蠢的嗎？這是一種可接受的方法嗎？

Answer 1

它看起來不錯。作爲攻擊者，我會嘗試直接向AppB僞造一個有效的請求＃2，看看會發生什麼。但是如果使用服務器端證書，只要它們不弱，我就不應該成功。

一些潛在的問題可能是

1. 暴力破解 - 如果它是你可能要考慮一個驗證碼或其他任何驗證碼，防止暴力破解兩個＃1和＃2高安全性和高流量。通常，您不會顯示前5-10個登錄名的驗證碼/驗證碼，然後您開始要求用戶表現得像人類一樣
2. ＃3和＃4 - 確保無法「檢查」該用戶是否無論是註冊還是不註冊您的用戶池，以及（更重要的）密碼是否有效。信息泄露或類似的東西可以幫助攻擊者枚舉用戶或知道電子郵件（您的登錄名）是否在您的數據庫中，這是任何社會工程攻擊的開始。
3. 重播攻擊：是否有人可能攔截＃2請求回覆服務器？我認爲這是錯誤的，因爲你使用HTTPs。
4. ＃2會話時間 - AppA和AppB之間的會話持續多久？通常s2s（系統2系統）通道沒有會話（即AppA始終發送憑證）或無限會話（AppA第一次設置會話ID，並且它將永遠持續）。在第二種情況下，確保會話ID至少不可重複使用。一場會議大概不會超過一週。
5. SSRF &類似：我們的pentesting清單中一個奇特的新項目。這裏沒有什麼特別的東西，但是確保沒有人可以使用AppA向AppB發出請求 - 例如，如果在＃5中，要求AppB的東西可以由用戶控制，那麼這是一個問題，請對輸入用戶進行清理。
6. 固定數據包：如果你有很小的HTTP請求，每次都差不多（＃2是一個很好的目標），它們可能處於像CRIME和BREACH這樣的HTTPs攻擊的大傘下。無論如何，這是一個複雜的話題，我只是提到了可能性，但對於那些適用的話題，還有很多事情需要考慮。
7. AppB的服務器端憑證 - 更新密碼：問問自己，如果AppA配置文件與它們一起被盜，改變它有多難？如果答案「幾乎不可能」，那麼這是一個關鍵性問題。你應該考慮每3-6-12個月更換一次這樣的密碼。

我在本說明中最後沒有看到任何關鍵內容。