Owasp - 2023 Top 10

https://www.canva.com/design/DAFnojIXJzY/fQBmtACIUXdpx9RBRlFN5g/view?utm_content=DAFnojIXJzY&utm_campaign=designshare&utm_medium=link&utm_source=publishsharelink ## API1:2023 Broken Object Level Authorization 通常資料庫在存取物件時，會利用ID的方式識別資料，那api的端點(API 端點是 API 通訊系統中最終的接觸點。這些包括伺服器 URL、服務以及其他特定數位地點，相關資訊則是透過此處在系統間傳送與接收。)有可能就可以傳送ID等，如範例的URL，數字1則是物件的ID。若權限驗證沒有控制好，攻擊方就能透過發送含有ID的Request進而使用不安全的API，使得未經授權的資料洩漏、竄改或損毀。 情況1，URL利用shopname去儲存資料，若存在Broken object level Authorization，此時攻擊者有商店的名稱，即可獲取商店所存放的資料。情況2，api透過車號啟動車輛或解鎖車門，當api不做驗證時，很容易造成攻擊者能使用不屬於他的車輛。情況3，AT&T有一個功能，可以通過HTTP請求提交設備的SIM卡ICC-ID並返回電子郵件位址。通過提交不同的ICC-ID（可能屬於另一個Apple客戶），該實用程式將返回不同的電子郵件。這允許攻擊者訪問超過100，000個客戶電子郵件位址，包括軍事、政府和媒體部門高級人員的電子郵件位址。 說到這個，我們學校之前有一個easytest的網頁，可以提供學生測驗自己的多益，老師也常常拿來考試用，就有這個問題。當時只要把成績那頁的URL最後的數字改掉，就可以看到其他人的成績，所以可以用這東西查詢別人的成績以及答案，算是很大的漏洞。不過似乎在去年有修掉了。 #### 預防方式 * Implement a proper authorization mechanism that relies on the user policies and hierarchy.(實施適當的授權機制，依賴於使用者的策略和層級結構：這意味著應該建立一個明確的授權機制，該機制基於使用者的權限和角色層級。使用者的授權應該根據其在系統中的角色和組織位置來決定，以確定他們可以執行哪些操作。)：建立明確的授權機制，依照使用者的定位層級，確保使用者可以執行的操作。 * Use the authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database.(在每個使用來自客戶端的輸入來訪問數據庫記錄的函數中使用授權機制檢查已登入的使用者是否有權限執行所請求的操作：這表示在處理每個輸入的數據時，都應該使用授權機制來驗證已登入的使用者是否有權限執行所請求的操作。這確保只有具有適當權限的使用者可以訪問和修改相應的記錄。)：在處理每個請求以及數據時，應該使用驗證機制確認登入的使用者能否執行該操作，確保只有適當權限的使用者可以訪問或修改。 * Prefer the use of random and unpredictable values as GUIDs for records' IDs.(優先使用隨機且不可預測的值作為記錄的唯一識別碼)：為了增加安全性，應該使用隨機生成的全局唯一識別碼（GUID）來標識和辨別數據庫中的記錄。這樣可以防止攻擊者根據預測的ID進行猜測和操作記錄。 * Write tests to evaluate the vulnerability of the authorization mechanism. Do not deploy changes that make the tests fail.(撰寫測試來評估授權機制的漏洞性，並不要部署導致測試失敗的更改)：為了確保授權機制的有效性和安全性，應該撰寫相應的測試案例來測試該機制。這些測試案例應該驗證使用者是否可以成功執行預期的操作，並確保不會有未經授權的訪問。在部署應用程式時，確保這些測試通過，並避免導致測試失敗的更改被部署到生產環境中。 ## API3:2023 Broken Object Property Level Authorization 正常情況下，系統或應用程式會對用戶或角色授予特定的訪問權限，以限制他們可以查看、修改或刪除的物件屬性。然而，當存在"Broken Object Property Level Authorization" 時，這些授權機制可能無法適當地區分不同用戶或角色對物件屬性的訪問權限。以下範例就是物件的形式，會有些資料是使用者不應該更改或訪問的，像是id或email之類的。若使用者可以透過api的端點進行修改。這種漏洞可能使得一些用戶或角色能夠訪問他們應該無權訪問的物件屬性，或者在某些情況下，可能會使他們能夠修改或刪除應該只能由特定用戶或角色訪問的屬性。 情況1:這是一個舉報程式，可以看到它裡面包含了不應該出現的資料，被舉報者的資訊暴露在回應中，像是fullname、以及recentlocation，只要使用者按下report便能看到其他使用者的資訊。情況2:這是一個出租仲介系統，可以看到原本的請求應該長這樣，但若攻擊者知道其他屬性的名稱，且若主機並未驗證此屬性是否使用者能使用，便會導致惡意請求成立，客戶將被收取更高的費用。情況3:這影片審查機制，若無物件屬性驗證，便可以透過更改blocked這屬性，繞過影片審查。 修復這種漏洞的方法可能涉及修正授權機制的實現，以確保對物件屬性的訪問權限正確地限制和執行。這可以通過進行適當的驗證和授權檢查，以確保每個用戶或角色只能訪問其應有的屬性 #### 預防方式 * When exposing an object using an API endpoint, always make sure that the user should have access to the object's properties you expose:僅公開用戶能訪問的屬性，確保數據的安全性和隱私，避免把敏感信息暴露給未經授權的用戶。 * Avoid using generic methods such as and . Instead, cherry-pick specific object properties you specifically want to return.to_json()to_string():避免把整個物件轉換成json、string等傳入，只挑特定的屬性傳入，減少不必要的數據。 * If possible, avoid using functions that automatically bind a client's input into code variables, internal objects, or object properties ("Mass Assignment"):避免直接將數據傳入api裡做使用。 * Allow changes only to the object's properties that should be updated by the client:只允許client端更新固定的對象屬性，這可確保只有合法的數據被更改，維持數據的一致性與安全性。 * Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods: 在api的部分多新增一個驗證機制，驗證數據是否符合預期的格式或結構。 * Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint:僅傳回api最小必要的數據，除了能提高傳輸的效能，同時確保安全性。 ## API5:2023 Broken Function Level Authorization 通常，應用程式的各個功能或操作都應該根據用戶的權限進行控制和限制。這樣可以確保用戶只能執行他們具有權限的操作，並防止未經授權的用戶進行敏感操作。然而，當存在"Broken Function Level Authorization"漏洞時，授權檢查不正確或不完整，使得用戶能夠執行他們不應該擁有的功能。因為現代應用程式可能包含許多類型的角色、組和複雜的用戶層次結構（例如子使用者或具有多個角色的使用者），在 API 中這些缺陷更容易出現。此安全漏洞與前面的BOLA不一樣的是，這個漏洞是針對這功能或服務，而BOLA是對物件資料。 情況1:下面的api可以獲取相關的使用者email與權限，攻擊者若修改這請求，而這個api原本應該只能由管理員使用，但因為沒有做Function Level Authorization，攻擊者便能幫自己創造一個同樣有管理員權限的帳戶，已讓自己有系統的完全控制權。情況2:這api原本只有管理員能夠知道，所以沒有Function Level Authorization，攻擊者了解並猜測後，得到該api，便能輕易地使用，獲取所有使用者資訊。 #### 預防方式 * The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.默認情況拒絕所有的request，針對每個功能明確的授予訪問權限，確保只有特定的用戶可以執行操作。 * Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy.仔細的檢查api的邏輯與使用者架構，確保授權符合預期。 * Make sure that all of your administrative controllers inherit from an administrative abstract controller that implements authorization checks based on the user's group/role.讓管理的控制都經由一個控制器檢查使用者的授權，確保所有的管理功能都能經過授權的驗證，並限制只有管理員能夠執行操作。 * Make sure that administrative functions inside a regular controller implement authorization checks based on the user's group and role.在一般的功能進行管理功能的檢查，確保只能有相應的角色個執行管理功能，以增強系統安全。 ## API7:2023 Server Side Request Forgery Server-Side Request Forgery (SSRF) 攻擊者利用這個漏洞，通過操縱服務器端應用程序的請求發送功能，使其發送未經授權的請求到內部網絡或外部資源。這可能導致多種風險，包括數據泄露、系統資源消耗、攻擊內部資源等。 SSRF 的攻擊方式通常涉及操縱服務器端應用程序接收的輸入數據，例如 URL、文件名等。攻擊者可以修改這些輸入，使服務器端應用程序發起請求到攻擊者指定的目標，而不是預期的目標。攻擊者可能將請求發送到內部資源，如數據庫、文件系統，甚至是其他網絡設備。也可以發送請求到外部資源，如其他網站、API 端點等。 SSRF 的威脅在於攻擊者可以利用內部網絡的特權訪問權限，獲取機密數據，執行未授權的操作，或進一步探測和攻擊其他內部系統。例如，攻擊者可以通過 SSRF 進行端口掃描、內部服務探測，或利用應用程序的身份進行身份欺騙和其他攻擊。 情況1:這是一個可以上傳圖片網址讓server獲取的api，攻擊者便可以使用localhost這種方式，根據他的回應時間，檢測server端的port是否有打開。 情況2: 這裡我提供一個我找到的另外一種情況，以下是一個能夠新增的留言的後端api介面: ``` 新增留言： POST http://internal.corp.com/${userId}/posts?message=${message}&token=${token} 管理者更新留言： POST http://internal.corp.com/admin/posts/${postId}?message=${message} ``` 新增留言的部分有使用token驗證使用者身分，userid是使用者編號，message是留言內容。管理者更新留言，postid是留言的編號，因為方便沒有使用token驗證，設計者可能也覺得這api並未公開，也寫在內部的sever，所以很安全。 ![](https://hackmd.io/_uploads/BJ5b6WlF3.png) 那今天有個駭客透過一些方式獲取到管理這api，那他想要惡意得更改別人的留言，留言id是1234，他呼叫更新留言的api，但動了點手腳，把userid改成: ``` admin%2Fposts%2F1234%3Fmessage%3Dhacked%26 ``` 那這個字串透過是透過URL編碼所得到的結果，若解碼則會變成: ``` admin/posts/1234?message=hacked& ``` 整體會變成: ``` http://internal.corp/com/admin/posts/1234?message=hacked& ``` 因為不需要token驗證，所以駭客可以輕易地達成他要的結果。 #### 預防方式 * Isolate the resource fetching mechanism in your network:確保使用者只能使用外不得資源，限制內部資源的訪問 * Whenever possible, use allow lists of: 1. Remote origins users are expected to download resources from (e.g. Google Drive, Gravatar, etc.):透過預期的來源下載資源 2. URL schemes and ports:給特定的URL或是port 3. Accepted media types for a given functionality:給定這功能所接受的資料媒體型態 * Disable HTTP redirections:禁止HTTP重新定向，防止攻擊者導向不信任的資源 * Use a well-tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies:使用有良好測試與維護的URL解析器 * Validate and sanitize all client-supplied input data:驗證客戶端提供的數據 * Do not send raw responses to clients:不要把原始的回應直接給客戶端，適當的使用加密或編碼 ## API9:2023 Improper Inventory Management 指沒有對現有的資源(例如:硬體、軟體、網路設備等)進行有效的管理，沒有使用的並沒有及時清理，導致這些資源可能會有安全疑慮，容易被利用來入侵系統。除此之外，沒有管理的資源將會提高營運成本以及維護的難度。漏洞始於舊的或未修補的 API。如果沒有通常通過更新或升級到具有更好支援的較新 API 版本提供的安全功能，攻擊者可以使用已知缺陷繞過安全性。從管理方面來看，正在運行的 API 實例的部分、不完整或過時的清單可以為我們剛剛提到的舊的和未修補的 API 建立空間。OWASP報告還提到，目的不明的API主機，或者沒有明確記錄的有關API運行環境，版本，使用和訪問的資訊或誰應該有權訪問API的問題答案肯定是脆弱的。其他因素包括沒有生命週期和停用策略的 API。 #### 預防方式 * Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g. production, staging, test, development), who should have network access to the host (e.g. public, internal, partners) and the API version. * Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and their sensitivity. * Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy, and endpoints, including their parameters, requests, and responses. * Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline. * Make API documentation available only to those authorized to use the API. * Use external protection measures such as API security specific solutions for all exposed versions of your APIs, not just for the current production version. * Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones. * When newer versions of APIs include security improvements, perform a risk analysis to inform the mitigation actions required for the older versions. For example, whether it is possible to backport the improvements without breaking API compatibility or if you need to take the older version out quickly and force all clients to move to the latest version. 1. 清點所有的api主機以及紀錄，包括api的暫存、開發環境、測試環境等。確定api的網路訪問權限，以及版本訊息。 2. 清點整體的服務和重要資料，像是系統角色定位、數據、以及機密性。 3. 對api的整體做文檔的紀錄，像身分驗證、錯誤回報、重新定向、CORS政策，還有接口的參數、請求回應等。 4. 採用開放標準生成文件。將文件建構流程納入CI/CD(持續整合與持續部署。簡單來說，就是把一些日常的建置環境、測試、build，一直到部署都交給自動化的工具，目的除了加快開發流程之外，也可以提早發現問題。)。 5. 確保api的文件只有有授權的人看的到。 6. 使用外部的保護措施，只要有公開的api都要，不只當前版本。 7. 避免使用非生產API部署的生產數據。如果這是不可避免的，這些終點應獲得與生產的安全處理相同的安全處理。 8. 當API的新版本包括安全性改進時，執行風險分析以告知較舊版本所需的緩解操作。例如，是否可以在不破壞API兼容性的情況下進行改進，還是需要快速將舊版本取出並迫使所有客戶端轉移到最新版本。