API設計和安全性：為什么要隱藏內部ID？

Question

我聽說有些人說你不應該把你的內部ID暴露給外面的世界（例如auto_increment'ng主鍵）。

有人建議使用某種uuid列來代替查找。

我想知道為什么會這樣建議，如果真的很重要的話。

使用uuid基本上只是混淆了id。 重點是什么？ 我唯一能想到的是auto_incrementing整數顯然指出了我的db對象的順序。 如果外部用戶知道有一件事是在另一件事之前/之后創造的，那有關系嗎？

或者純粹是混淆id會阻止對特定對象的不同操作進行“猜測”？

在設計面向外部的API時，這是否是我應該考慮的問題？

Answer 1

很好的答案，我將添加另一個原因，為什么你不想暴露你的內部自動增量ID。
作為一家有競爭力的公司，我可以輕松地檢測每周/每天/每小時有多少新用戶/訂單/等。 我只需要創建一個用戶和/或訂單，並從我上次獲得的內容中減去新的ID。
因此，不僅出於安全原因，還有商業原因。

Answer 2

您向惡意用戶提供的有關您的應用程序及其布局的任何信息都可以用於您的應用程序。 我們在（網絡）應用程序安全性方面遇到的一個問題是，當項目規模擴大時，在項目的初期階段看似無害的設計決策將成為跟腱。 讓攻擊者對實體的排序做出明智的猜測可以回過頭來困擾你，有些不相關：

1. 實體的ID將不可避免地作為參數傳遞到應用程序中的某個點。 這將導致黑客最終能夠提供他們通常無法訪問的應用程序參數。 我個人能夠查看訂單詳情（在一個非常受歡迎的零售商的網站上），我沒有業務查看，作為URL參數不少。 我只是從我自己的合法訂單中提供應用順序號碼。

2. 知道主鍵字段值的限制或至少進展是SQL注入攻擊的寶貴資料，我無法在此討論。

3. 鍵值不僅用於RDBMS系統，還用於其他鍵值映射系統。 想象一下，如果JSESSION_ID cookie命令可以預先確定或猜到？ 每個有反對意見的人都會在網絡應用中重播會話。

還有更多，我相信其他人會在這里提出。

海豹突擊隊6並不一定意味着有6支海豹隊。 只是讓敵人猜測。 而且，潛在攻擊者猜測的時間在你的口袋里是更多的錢。

Answer 3

與許多與安全相關的問題一樣，這是一個微妙的答案 - kolossus提供了一個很好的概述。

它有助於了解攻擊者如何破壞您的API，以及發生了多少安全漏洞。

大多數安全漏洞都是由漏洞或疏忽引起的，攻擊者會尋找這些漏洞。 試圖破壞您的API的攻擊者將首先嘗試收集有關它的信息 - 因為它是一個API，可能是您發布了詳細的使用文檔。 攻擊者將使用此文檔，並嘗試許多不同的方法來使您的網站崩潰（從而暴露更多信息，如果他很幸運），或以您未預料到的方式做出反應。

你必須假設攻擊者有很多時間，並且會編寫攻擊腳本來嘗試每一條大道 - 就像一個無限時間的竊賊，圍着你的房子試着每一個門窗，用一個從每次嘗試中學到的鎖定選擇。

因此，如果您的API公開了類似getUserInfo(userid)的方法，並且userID是一個整數，則攻擊者將編寫一個腳本，從0向上迭代以查找您擁有的用戶數。 他們會嘗試負數， max(INT) + 1 。 您的應用程序可能會在所有這些情況下泄漏信息，並且 - 如果開發人員忘記處理某些錯誤 - 可能會泄露超出您預期的數據。

如果您的API包含限制訪問某些數據的邏輯 - 例如，您被允許為您的朋友列表中的用戶執行getUserInfo - 攻擊者可能會因為某個錯誤或疏忽而獲得一些數字，並且他會知道他得到的信息與有效用戶有關，因此他們可以建立應用程序設計方式的模型。 這相當於一個竊賊知道你所有的鎖都來自一個制造商，所以他們只需要帶上那個鎖扣。

就其本身而言，這可能對攻擊者沒有任何好處 - 但它使他們的生活變得更加容易。

鑒於使用UUID或其他無意義標識符的努力，可能值得讓攻擊者更加努力。 當然，這不是最重要的考慮因素 - 它可能不會使您應該采取的前5項措施來保護您的API免受攻擊者的侵害 - 但它有所幫助。