所以我有一個安靜的 API 負責處理我的應用程式的許可證，它記錄
- 用戶身份
- 用戶電子郵件
- 用戶名
- 執照到期日
目前發生的情況是用戶通過第三方身份驗證服務 (firebase) 進行身份驗證，然后應用程式從 firebase 身份驗證回應中獲取用戶 ID，并在未經許可 API 任何授權的情況下獲取許可資訊。 本質上，如果您有用戶 ID，您可以獲得上述所有資訊
我的問題：這是一個安全漏洞嗎？或者考慮到惡意用戶很難獲得另一個用戶的 ID 并且即使他獲得了 ID 資訊也不是那么有用，這是否可以接受
uj5u.com熱心網友回復：
這是一個資料保護問題，而不是一個編程問題，您在評論中從錯誤的角度看待它。資訊安全和資料保護以及具有不同心態的完全不同的作業。
User ID - personal data
User email - personal data
Username - personal data
license expiry date - probably company secret
我們在這里保護什么？
一些不那么敏感的個人資料，例如用戶名和電子郵件，可以通過查看公司網頁或鏈接來猜測。我想許可證的到期日期并不那么重要，也許公司想保密，誰知道呢，最好問問他們。如果只在此處使用用戶 ID，則沒什么大不了的。
當有人獲得用戶 ID 時會發生什么？
他們可以 24/7 全天候觀看上層資料，直到您添加正確的身份驗證或更改用戶 ID。他們如何得到它并不重要，讓我們假設他們可以。他們可以查看 HTTP 資料包，或者員工不小心將其發送給某人，或者他們從資料庫中竊取這部分，或者當您丟棄有故障的 HDD 時，他們從 HTTP 服務器日志中獲取它，誰在乎？！
對貴公司會有什么影響？
如果您的客戶不關心它，那好吧。如果他們會立即終止合同并向當局報告資料保護事件，您將被起訴等，那么這是一個問題......
還能發生什么？
你有支持嗎？有人可以使用用戶 ID 和上面的資訊來欺騙您的支持終止合同并將錢退回到他們提供的銀行賬戶嗎？如果是這樣，那么這也是一個問題。
風險評估是關于檢查諸如鞋面之類的事情的概率、動機、后果等，并在必要時通過降低風險的保護措施來減輕它們。例如，如果可以通過 FireBase 發送加密簽名的 JWT，則可以在將用戶 ID 和會話到期日期發送到您的 API 之前對其進行加密和簽名。
uj5u.com熱心網友回復：
如果訪問記錄的唯一方法是隨機生成的 UUID，那么將 UUID 視為“密鑰”并知道它相當于身份驗證令牌是合理的。UIUD 空間極其稀疏；它們不可猜測，就像 AES 密鑰不可猜測一樣。因此，資料與 UUID 一樣受到保護。當然，您仍然應該使用 HTTPS 來保護傳輸中的 URL。我經常使用這些型別的方案（知道 UUID 或知道資料的 SHA 是身份驗證）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/504335.html
上一篇：在聊天應用程式中檢索訊息