事件經過
Base44 是一個讓人用日常語言描述需求、就能做出可運作應用程式的平台，後來被 Wix 收購。企業曾用它建內部工具：給員工用的聊天助手、知識庫，以及存放個人資料與員工紀錄的系統。資安研究團隊 Wiz Research 著手檢視這類平台如何處理登入。
研究人員先列出 Base44 的公開網址，找到大約五個，全都很普通：應用程式本身、說明文件與行銷網站。其中兩個網址提供的頁面，讓任何訪客都能瀏覽並試打平台內建的請求。這些請求裡，有一個會為某個應用程式建立新的使用者帳號，還有一個會用寄到電子郵件的驗證碼確認該帳號。
每個建在 Base44 上的應用程式都帶有一個識別碼，它印在應用程式的網址裡，也印在應用程式對外公開的一個檔案中。Base44 提供應用程式擁有者幾種存取設定可選，其中最嚴格的一種，限定只有受邀員工透過公司登入才能進入。研究人員拿了一個設成這種模式、而且不屬於他們的應用程式的識別碼，建立了一個帳號、用電子郵件收到確認碼、完成確認，接著從該應用程式自己的登入頁登了進去。
Wiz Research 回報，同樣的做法在受影響企業的多個私有應用程式上都行得通，涵蓋內部聊天助手、知識庫、個人資料與員工作業。他們也藉由比對登入頁與自訂網址的共同特徵，在外部找出這類應用程式，並通知了自己的部分客戶。
這份回報在 7 月送交 Base44 與 Wix。Wix 當天就確認收到，並表示正在進行修復；修復在不到 24 小時內完成，隔天研究人員驗證外部人士已無法再註冊到私有應用程式。數天後，Wix 表示問題已解決，並回報在 Base44 的使用者群中沒有跡象顯示遭到入侵。Base44 的聲明表示：「我們已進行調查，到目前為止，沒有發現任何客戶因攻擊者利用此漏洞而受到影響的證據」，且調查仍在進行中。公開揭露在當月稍晚進行。Wiz 表示客戶不需要採取任何行動，並建議組織檢視自家應用程式的紀錄，留意異常的造訪與註冊。
主要來源——S1：https://www.wiz.io/blog/critical-vulnerability-base44存檔快照
損失成因
- 註冊與電子郵件確認這兩個步驟，把「知道某個應用程式的識別碼」當成加入它的權限，而那個識別碼就印在應用程式自己的網址上 這個識別碼從來不是祕密；它出現在網址列，也出現在每個應用程式對外公開的一個檔案裡。因為在建立帳號之前，除了那個識別碼之外沒有衡量任何其他東西，光是讀網址就足以開始成為一個私有應用程式的使用者。技術名稱：可直接存取的物件參考（IDOR）（insecure direct object reference）
- 建立帳號與確認帳號的步驟在任何登入之前就執行，所以沒有人需要證明自己是誰才能使用它們，應用程式的隱私設定也沒有被查看 在應用程式首頁並沒有檢查到這兩個步驟。一個帶著電子郵件位址、密碼與應用程式識別碼的請求，就產生了一個已確認的帳號，接著一般的登入流程就直接接受這個帳號。技術名稱：未經身分驗證的存取（unauthenticated access）
- 平台上每個應用程式都同一套規則運作，因此這套規則裡的一個弱點會同時觸及每一位客戶的私有應用程式。 受影響的企業選的是供應商所提供最嚴格的設定，而那個選擇被套用在失守步驟的上一層。沒有任何客戶能自行限縮加入路徑，因為這個設定屬於整個平台，並由平台上所有應用程式共享。技術名稱：生產與開發共用基礎設施（shared prod-dev infrastructure）
判讀
一個私有空間，只有在每一道門都會驗證來者是誰的時候，才算私有。當註冊與電子郵件確認這兩道門跳過了這項檢查，私有工作空間的識別碼就不再是祕密，而變成一張邀請函；看得到它的人都能加入。守住首頁、卻讓加入的路徑敞開，等於什麼都沒守住。
自我查核
只有你能回答的
- 當你把應用程式設成最嚴格的選項、並開啟公司登入時，你認為那代表誰才能在裡面建立帳號？另外，有什麼東西可以被放到這個應用程式裡？
- 你知道自己跑在供應商「用描述生成」平台上的哪些應用程式，存放著員工紀錄、客戶個人資料或人資素材嗎？在明白加入規則屬於供應商、且與其他所有客戶共用的情況下，你還會把它們留在那裡嗎？
- 如果供應商明天告訴你，外人有可能在你的私有應用程式裡建立過帳號，你公司裡由誰決定要對員工與客戶說什麼？這件事有沒有在需要它之前就先講定？
你的 AI 可以幫你查的
只做回報；不要更動任何程式碼或設定。每個答案都附上檔案或主控台的出處，並在無法從你所能看到的資訊判斷時，明白說出來。
- 針對我們營運的每一個應用程式，列出它的應用程式識別碼或租戶識別碼出現在哪些外部人士讀得到的地方：網址、manifest 或類似的公開檔案、頁面原始碼、sitemap，以及廠商說明文件。接著列出伺服器端每一條把該識別碼當成唯一有意義輸入的路由，並回報在該路由據以行動之前會執行什麼授權檢查；附上檔案或主控台出處。
- 列舉我們自己程式碼中，不需要有效的 session 或 token 就能到達的每一條路由，特別留意註冊、接受邀請、密碼重設，以及一次性驗證碼的驗證。針對每一條，回報在帳號被建立或被確認之前，伺服器端是否有驗證應用程式的隱私或成員資格設定；附上檔案或主控台出處。
- 回報這個專案是否有一項自動化測試：嘗試對一個呼叫者未受邀請的應用程式進行註冊與驗證，斷言該嘗試會失敗，並且在每次變更時都會執行；附上檔案位置，若沒有這樣的測試就直說。
- 盤點每一個替我們營運應用程式的第三方「用描述生成」、低程式碼或託管平台。針對每一個，回報：在廠商的網域上，是否有像 Swagger-UI 這類可互動的 API 說明文件頁面不需登入就能到達；廠商是否發布資安公告或狀態訊息、我們有沒有訂閱；以及我們有哪些應用程式把個人、人資或客戶資料放在該共用平台上；附上檔案或主控台出處。
預防方式
把應用程式的識別碼當成地址，不是門鎖。 假設那個標示你應用程式名稱的字串是公開的，因為它就在網址裡。請託管你應用程式的廠商以書面確認：只握有那個識別碼、其他什麼都沒有的人，無法在裡面建立帳號；並請他們指名這項承諾涵蓋哪些路徑：註冊、電子郵件確認、邀請，以及密碼重設。
取得帳號可能被建立出來的所有途徑清單。 以書面向供應商索取：你的應用程式的新使用者可以透過哪些途徑被建立，以及每一條途徑上會檢查誰。接著請他們每月寄給你一份在你私有應用程式中被建立的帳號清單，拿它對照你自己的員工名冊；這是一份你不必動到產品就能據以行動的報表。
假設你繼承了供應商的資安水準，並據此安放你的資料。 既然加入規則屬於平台、且由它的所有客戶共用，就要刻意決定什麼可以放在那裡：在供應商以書面回答上述問題之前，員工紀錄、客戶個人資料與人資素材都別放上共用平台；並在合約中要求，當這類缺陷被發現與修復時，他們必須直接、迅速地告知你。
你選的設定，只能保護到供應商自己那幾道門為止。