Server-side vulnerabilities - Access Control

 

Bài viết gốc

Access control vulnerabilities and privilege escalation

Trong phần này, chúng tôi mô tả:

• Leo thang đặc quyền.
• Các loại lỗ hổng có thể phát sinh với kiểm soát truy cập.
• Làm thế nào để ngăn chặn các lỗ hổng kiểm soát truy cập.

What is access control?

Kiểm soát truy cập là việc áp dụng các ràng buộc về ai hoặc cái gì được ủy quyền thực hiện các hành động hoặc truy cập các tài nguyên. Trong ngữ cảnh của các ứng dụng web, kiểm soát truy cập phụ thuộc vào authentication và session management:

• Authentication xác nhận người dùng là ai.
• Session management xác định các yêu cầu HTTP tiếp theo được thực hiện bởi cùng một người dùng.
• Access control xác định liệu người dùng có được phép thực hiện hành động mà họ đang cố gắng thực hiện hay không.

Kiểm soát truy cập bị lỗi là một lỗi bảo mật phổ biến và thường rất nguy hiểm. Thiết kế và quản lý kiểm soát truy cập là một vấn đề phức tạp và động thay đổi liên tục, áp dụng các ràng buộc kinh doanh, tổ chức và pháp lý cho một cài đặt kỹ thuật. Các quyết định thiết kế kiểm soát truy cập phải được đưa ra bởi con người nên khả năng xảy ra lỗi là cao.

Vertical access controls

Kiểm soát truy cập theo chiều dọc là các cơ chế hạn chế quyền truy cập vào chức năng nhạy cảm đối với những loại người dùng cụ thể. 

Với các biện pháp kiểm soát truy cập theo chiều dọc, các loại người dùng khác nhau có quyền truy cập vào các chức năng ứng dụng khác nhau. Ví dụ: quản trị viên có thể sửa đổi hoặc xóa bất kỳ tài khoản nào của người dùng, trong khi người dùng thông thường không có quyền truy cập vào các hành động này.

Horizontal access controls

Kiểm soát truy cập theo chiều ngang là các cơ chế hạn chế quyền truy cập vào tài nguyên đối với những người dùng cụ thể. 

Với các điều khiển truy cập theo chiều ngang, những người dùng khác nhau có quyền truy cập vào một tập hợp con các tài nguyên cùng loại. Ví dụ: một ứng dụng ngân hàng sẽ cho phép người dùng xem các giao dịch và thực hiện thanh toán từ tài khoản của chính họ chứ không phải tài khoản của bất kỳ người dùng nào khác.

Context-dependent access controls

Kiểm soát truy cập phụ thuộc vào ngữ cảnh hạn chế quyền truy cập vào chức năng và tài nguyên dựa trên trạng thái của ứng dụng hoặc sự tương tác của người dùng với nó. 

Kiểm soát truy cập phụ thuộc vào ngữ cảnh ngăn người dùng thực hiện các hành động không đúng thứ tự. Ví dụ: một trang web bán lẻ có thể ngăn người dùng sửa đổi nội dung giỏ hàng của họ sau khi họ đã thanh toán.

Examples of broken access controls

Lỗ hổng kiểm soát truy cập bị hỏng tồn tại khi người dùng có thể truy cập tài nguyên hoặc thực hiện các hành động mà lẽ ra họ không thể thực hiện được.

Vertical privilege escalation

Nếu người dùng có thể có quyền truy cập vào chức năng mà họ không được phép truy cập thì đây là leo thang đặc quyền theo chiều dọc. Ví dụ: nếu người dùng không phải quản trị viên có thể có quyền truy cập vào trang quản trị nơi họ có thể xóa tài khoản người dùng thì đây là leo thang đặc quyền theo chiều dọc.

Unprotected functionality

Ở mức cơ bản nhất, việc leo thang đặc quyền theo chiều dọc phát sinh khi ứng dụng không thực thi bất kỳ biện pháp bảo vệ nào đối với chức năng nhạy cảm. Ví dụ: các chức năng quản trị có thể được liên kết từ trang chào mừng của quản trị viên nhưng không được liên kết từ trang chào mừng của người dùng. Tuy nhiên, người dùng có thể truy cập các chức năng quản trị bằng cách duyệt đến URL quản trị viên có liên quan.

Ví dụ: một trang web có thể lưu trữ chức năng nhạy cảm tại URL sau:

https://insecure-website.com/admin

Bất kỳ người dùng nào cũng có thể truy cập được trang này, không chỉ người dùng quản trị có liên kết đến chức năng trong giao diện người dùng của họ. Trong một số trường hợp, URL quản trị có thể được tiết lộ ở các vị trí khác, ví dụ như file robots.txt:

https://insecure-website.com/robots.txt

Ngay cả khi URL không được tiết lộ ở bất kỳ đâu, kẻ tấn công vẫn có thể sử dụng danh sách để xác định vị trí của chức năng nhạy cảm.

Lab: Unprotected admin functionality

Lab này có bảng quản trị không được bảo vệ.

Vượt qua bài kiểm tra này bằng cách xóa người dùng carlos.

ACCESS THE LAB

Solution

1. Đi đến lab và xem robots.txt bằng cách thêm /robots.txt vào lab URL. Chú ý rằng dòng Disallow tiết lộ đường dẫn đến bảng quản trị.

2. Trên thanh địa chỉ, thay /robots.txt bằng /administrator-panel để tải admin panel.

3. Delete carlos.

Trong một số trường hợp, chức năng nhạy cảm bị ẩn bằng cách đặt cho nó một URL ít dự đoán hơn. Đây là một ví dụ về cái gọi là "bảo mật bằng cách tối nghĩa". Tuy nhiên, việc ẩn chức năng nhạy cảm không mang lại khả năng kiểm soát truy cập hiệu quả vì người dùng có thể phát hiện ra URL bị xáo trộn theo một số cách.

Hãy tưởng tượng một ứng dụng lưu trữ các chức năng quản trị tại URL sau:

https://insecure-website.com/administrator-panel-yb556

Kẻ tấn công có thể không đoán được điều này một cách trực tiếp. Tuy nhiên, ứng dụng vẫn có thể rò rỉ URL cho người dùng. URL có thể được tiết lộ bằng JavaScript để xây dựng giao diện người dùng dựa trên vai trò của người dùng:

<script> var isAdmin = false; if (isAdmin) { ... var adminPanelTag = document.createElement('a'); adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556'); adminPanelTag.innerText = 'Admin panel'; ... } </script>

Tập lệnh này thêm liên kết vào giao diện người dùng của người dùng nếu họ là người dùng quản trị. Tuy nhiên, tập lệnh chứa URL sẽ hiển thị với tất cả người dùng bất kể vai trò của họ.

Lab: Unprotected admin functionality with unpredictable URL

Lab này có bảng quản trị không được bảo vệ. Nó nằm ở một vị trí không thể đoán trước, nhưng vị trí đó được tiết lộ ở đâu đó trong ứng dụng.

Giải quyết lab bằng cách truy cập bảng quản trị và sử dụng nó để xóa người dùng carlos.

ACCESS THE LAB

Solution

Xem mã nguồn bằng cách sử dụng Burp Suite hoặc developer tools trên trình duyệt của bạn. Quan sát rằng nó có chứa một số JavaScript tiết lộ URL của bảng quản trị.

Hoặc đơn giản hơn nhìn vào Site map cũng đã thấy

Truy cập admin panel và delete carlos.

Parameter-based access control methods

Một số ứng dụng xác định quyền truy cập hoặc vai trò của người dùng khi đăng nhập, sau đó lưu trữ thông tin này ở vị trí do người dùng kiểm soát. Đây có thể là:

• Một trường ẩn.
• Một cookie.
• Một tham số chuỗi truy vấn.

Ứng dụng đưa ra quyết định kiểm soát truy cập dựa trên giá trị được gửi. Ví dụ:

https://insecure-website.com/login/home.jsp?admin=true https://insecure-website.com/login/home.jsp?role=1

Cách tiếp cận này không an toàn vì người dùng có thể sửa đổi giá trị và chức năng truy cập mà họ không được phép, chẳng hạn như các chức năng quản trị.

Lab: User role controlled by request parameter

Lab này có bảng quản trị tại /admin, bảng này xác định những quản trị viên sử dụng cookie có thể giả mạo.

Giải quyết lab bằng cách truy cập bảng quản trị và sử dụng nó để xóa người dùng carlos.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Solution

1. Truy cập /admin và thấy rằng bạn không thể truy cập admin panel.
2. Truy cập trang đăng nhập.
3. Trong Burp Proxy, bật interception on để bắt request đăng nhập và bật response interception.
4. Quan sát response đặt giá trị cookie Admin=false, thay đổi nó thành Admin=true.

Nếu không làm thế này thì có thể mở Devtools lên và vào mục Application -> Cookies cũng sẽ thấy và thay đổi giá trị Admin thành true

5. Tải lại admin panel và xoá carlos.

Bài học rút ra là gì: 

Không lưu những thông tin quan trọng có thể sửa đổi được ở phía client :v

Lab: User role can be modified in user profile

Lab này có bảng quản trị tại /admin. Nó chỉ có thể truy cập được đối với người dùng đã đăng nhập vớiroleid là 2.

Giải quyết lab bằng cách truy cập bảng quản trị và sử dụng nó để xóa người dùng carlos.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Solution

Đăng nhập vào tài khoản được cung cấp, nhìn quanh một lượt không thấy có gì cả chỉ có mỗi mục update email thôi, dựa vào tên lab và mô tả của lab thì có nghĩa là mình sẽ update email và đồng thời gửi kèm thêm roleid = 2 theo.

Sử dụng BS bật Intercept để bắt request gửi update email và thêm roleid như hình và ấn Foward

Kết quả là sẽ hiển thị Admin panel và xoá user carlos đi thôi

Tại sao lại như vậy?

Trước hết thì trong thực tế chắc chả ai đoán được là phải dùng param nào để update đúng được như lab hướng dẫn, chắc chỉ có dev trong dự án tự phát hiện ra lỗi và nói cho người ngoài thôi.

Với kiến thức, kinh nghiệm và trải nghiệm của mình thì lỗi này hoàn toàn có thể xảy ra nếu dev lười, cụ thể là nếu chỉ cần update email thì update email thôi, trường hợp này là update vào từ cả payload luôn. Mình gặp phải khi dùng với mongodb thôi còn cái database khác mình không rõ.

Ví dụ minh hoạ

Broken access control resulting from platform misconfiguration

Một số ứng dụng thực thi các biện pháp kiểm soát truy cập ở lớp nền tảng. họ thực hiện điều này bằng cách hạn chế quyền truy cập vào các URL và phương thức HTTP cụ thể dựa trên vai trò của người dùng. Ví dụ: một ứng dụng có thể định cấu hình quy tắc như sau:

DENY: POST, /admin/deleteUser, managers

Quy tắc này từ chối quyền truy cập vào phương thức POST trên URL /admin/deleteUser, đối với người dùng trong nhóm người quản lý. Nhiều thứ có thể xảy ra sai sót trong tình huống này, dẫn đến việc bỏ qua kiểm soát truy cập.

Một số framework hỗ trợ nhiều HTTP header không chuẩn khác nhau có thể dùng để ghi đè URL trong yêu cầu ban đầu, chẳng hạn như X-Original-URL vàX-Rewrite-URL. Nếu một trang web sử dụng các biện pháp kiểm soát giao diện người dùng nghiêm ngặt để hạn chế quyền truy cập dựa trên URL nhưng ứng dụng cho phép ghi đè URL thông qua request header thì có thể bỏ qua các biện pháp kiểm soát truy cập bằng cách sử dụng một yêu cầu như sau:

POST / HTTP/1.1 X-Original-URL: /admin/deleteUser ...

Lab: URL-based access control can be circumvented

Trang web này có bảng quản trị chưa được xác thực tại /admin, nhưng hệ thống giao diện người dùng đã được định cấu hình để chặn quyền truy cập từ bên ngoài vào đường dẫn đó. Tuy nhiên, back-end của ứng dụng được xây dựng trên một framework hỗ trợ X-Original-URL header.

Để hoàn thành lab, hãy truy cập admin panel và xóa người dùng carlos.

ACCESS THE LAB

Solution

Thật sự mình cũng chưa hiểu về cái cách dùng header này như thế nào nên cũng hỏi AI thử thì được như sau

Vậy thì đọc xong mình hiểu là khi có header này thì server sẽ xử chuyển tiếp yêu cầu đến URL được để bên trong X-Original-Url, sau khi có kết quả thì nó trả kết quả về cái request mình yêu cầu, vậy thì /admin đã bị chặn từ phía client rồi thì mình sẽ request luôn trang chủ và để  X-Original-Url là /admin. Đoán thử vậy rồi dùng Repeater test phát.

Đúng thật luôn, giờ thì bật Intercept để bắt yêu cầu và chỉnh sửa để hoàn thành lab thôi.

Ẹc không dễ ăn lắm, nhìn cái url kia có lẽ là mình phải để X-Original-Url là /admin/delete?username=carlos. Thử lại phát.

Oke giờ báo thiểu param username, mình bổ sung thêm vào Url như thế này.

Vậy là giờ kết quả thành công rồi.

Lab: Method-based access control can be circumvented

This lab implements access controls based partly on the HTTP method of requests. Bạn có thể làm quen với admin panel bằng cách đăng nhập bằng thông tin đăng nhập administrator:admin.

Để vượt qua lab, hãy đăng nhập bằng thông tin đăng nhập wiener:peter và khai thác các biện pháp kiểm soát truy cập còn thiếu sót để thăng tiến bản thân trở thành quản trị viên.

ACCESS THE LAB

Solution

Truy cập vào admin panel của admin thì trông giao diện như này và sử dụng chức năng kiểm soát quyền của user mình sẽ lấy được api /admin-roles sau đó cho vào Repeater để sử dụng cho lần sau.

Có lấy được mỗi api thế thôi không tìm được gì khác, quay ra tài khoản user là wiener xem có gì không.

Mình cũng thử qua dăm 3 cái cách X-Original-Url như lần trước cũng không được.

Nhận ra là mình còn cái api lấy từ admin nên mình thay session của tài khoản wiener và thử gửi request xem sao.

Không được phép đương nhiên là hợp lý rồi, nhưng mà vẫn còn 1 thứ nữa mà mình còn bỏ sót từ ngay đầu đoạn hướng dẫn như này.

DENY: POST, /admin/deleteUser, managers

Mình hơi nghi ngờ là lab này sẽ chỉ chặn Method POST nên mình thử sửa nó thành DELETE xem vui vui thế nào

Ẹc biết ngay.

Chắc là cái hệ thống từ ngày xửa ngày xưa rồi mới còn cái lỗi thế này, chứ bây giờ đổi method 1 cái là báo lỗi 405 ngay.

Bài học rút ra:

Cứ làm Restful API là không lo cái lỗi kiểu như này nhé

Broken access control resulting from URL-matching discrepancies

Các trang web có thể khác nhau về mức độ nghiêm ngặt khi so sánh đường dẫn của một request đến một endpoint được xác định. Ví dụ, chúng có thể chấp nhận việc viết hoa không nhất quán, vì vậy một yêu cầu đến /ADMIN/DELETEUSER vẫn có thể được ánh xạ đến endpoint /admin/deleteUser . Nếu cơ chế kiểm soát truy cập khắt khe hơn, nó có thể coi đây là hai điểm cuối khác nhau và không thể thực thi cho cùng kết quả.

Những sự khác biệt tương tự có thể xảy ra nếu các nhà phát triển sử dụng Spring framework đã bật tùy chọn useSuffixPatternMatch. Tùy chọn này cho phép các đường dẫn có phần mở rộng tệp tùy ý được ánh xạ đến một điểm cuối tương đương không có phần mở rộng tệp. Nói cách khác, một yêu cầu đến /admin/deleteUser.anything vẫn sẽ khớp với mẫu /admin/deleteUser. Trước Spring 5.3, tùy chọn này được bật theo mặc định.

Trên các hệ thống khác, bạn có thể gặp phát sinh sự khác biệt trong việc xem xét liệu /admin/deleteUser và /admin/deleteUser/ có được xem xét như các điểm cuối khác biệt. Trong trường hợp này, bạn có thể vượt qua kiểm soát truy cập bằng cách thêm dấu gạch chéo cuối cùng vào đường dẫn.

Horizontal privilege escalation

Leo thang đặc quyền theo chiều ngang xảy ra nếu người dùng có thể có quyền truy cập vào tài nguyên thuộc về người dùng khác, thay vì tài nguyên thuộc loại đó của chính họ. Ví dụ: nếu một nhân viên có thể truy cập vào hồ sơ của các nhân viên khác cũng như của chính họ thì đây là sự leo thang đặc quyền theo chiều ngang.

Các cuộc tấn công leo thang đặc quyền theo chiều ngang có thể sử dụng các loại phương pháp khai thác tương tự như leo thang đặc quyền theo chiều dọc. Ví dụ: người dùng có thể truy cập trang tài khoản của chính họ bằng URL sau:

https://insecure-website.com/myaccount?id=123

Nếu kẻ tấn công sửa đổi giá trị thông số id thành giá trị của thông số của người dùng khác, thì chúng có thể có quyền truy cập vào trang tài khoản của người dùng khác cũng như các chức năng và dữ liệu liên quan.

Ghi chú

Đây là một ví dụ về lỗ hổng tham chiếu đối tượng trực tiếp (IDOR) không an toàn. Loại lỗ hổng này phát sinh khi các giá trị tham số của bộ điều khiển người dùng được sử dụng để truy cập trực tiếp vào tài nguyên hoặc chức năng.

Lab: User ID controlled by request parameter

Lab này có lỗ hổng leo thang đặc quyền theo chiều ngang trên trang tài khoản người dùng.

Để giải quyết lab, hãy lấy khóa API cho người dùng carlos và gửi khóa đó làm giải pháp.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Trong một số ứng dụng, tham số có thể khai thác không có giá trị dự đoán được. Ví dụ: thay vì số tăng dần, ứng dụng có thể sử dụng số nhận dạng duy nhất toàn cầu (GUID) để nhận dạng người dùng. Điều này có thể ngăn kẻ tấn công đoán hoặc dự đoán mã định danh của người dùng khác. Tuy nhiên, GUID thuộc về những người dùng khác có thể được tiết lộ ở nơi khác trong ứng dụng nơi người dùng được tham chiếu, chẳng hạn như tin nhắn hoặc bài đánh giá của người dùng.

Solution

Đây là một lab khá đơn giản, đăng nhập vào tài khoản được cung cấp và sẽ thấy như sau

Thay đổi user id trên url thành carlos là lấy được API key rồi submit thôi.

Lab: User ID controlled by request parameter, with unpredictable user IDs

Lab này có lỗ hổng leo thang đặc quyền theo chiều ngang trên trang tài khoản người dùng nhưng xác định người dùng bằng GUID.

Để vượt qua lab, hãy tìm GUID cho carlos, sau đó gửi khóa API của anh ấy để hoàn thành.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Solution

1. Đăng nhập vào tài khoản được cung cấp thấy my-account?id=688af7e3-0d47-47d7-904b-566b86bd6deb thanh URL là  và API key như sau

2. Giờ phải đi tìm lấy id của carlos thôi, sau một lúc loay hoay tìm kiếm đến tận bài viết cuối cùng thì mình mới thấy
 

3. Copy lấy userId và quay lại trang tài khoản cá nhân, thay userId của mình thành userID của carlos vừa tìm được

Vậy là lấy được API key rồi, công ty mình có mua 1 cái source của các pháp sư Ấn Độ về mà tưởng code xịn xò thế nào thì đập ngay vào mắt là cũng thấy cái lỗ hổng kiểu này, thậm chí còn để ID tăng dần mới dễ mò chứ -.- 

Lab: User ID controlled by request parameter with data leakage in redirect

Lab này chứa một lỗ hổng kiểm soát quyền truy cập, trong đó thông tin nhạy cảm bị rò rỉ trong nội dung phản hồi chuyển hướng.

Để giải quyết lab, hãy lấy khóa API cho người dùng carlos.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Solution

Login vào lab với tài khoản được cung cấp, thử đổi userid thành carlos và ta bị đẩy ra trang login

Xem trong tab network thì vẫn thấy request được gửi đi nhưng ta không thấy được kết quả bên trong. Quay ra BS và sử dụng Repeater để kiểm tra thử và thấy kết quả như sau.

Copy API key và hoàn thành lab thôi.

Horizontal to vertical privilege escalation

Thông thường, một cuộc tấn công leo thang đặc quyền theo chiều ngang có thể biến thành một cuộc tấn công leo thang đặc quyền theo chiều dọc bằng cách xâm phạm người dùng có đặc quyền hơn. Ví dụ: leo thang theo chiều ngang có thể cho phép kẻ tấn công đặt lại hoặc lấy được mật khẩu của người dùng khác. Nếu kẻ tấn công nhắm mục tiêu vào người dùng quản trị và xâm phạm tài khoản của họ thì họ có thể có được quyền truy cập quản trị và thực hiện leo thang đặc quyền theo chiều dọc.

Kẻ tấn công có thể có quyền truy cập vào trang tài khoản của người dùng khác bằng cách sử dụng kỹ thuật giả mạo tham số đã được mô tả để leo thang đặc quyền theo chiều ngang:

https://insecure-website.com/myaccount?id=456

Nếu người dùng mục tiêu là quản trị viên ứng dụng thì kẻ tấn công sẽ có quyền truy cập vào trang tài khoản quản trị. Trang này có thể tiết lộ mật khẩu của quản trị viên hoặc cung cấp phương tiện thay đổi mật khẩu hoặc có thể cung cấp quyền truy cập trực tiếp vào chức năng đặc quyền.

Lab: User ID controlled by request parameter with password disclosure

Lab này có trang tài khoản người dùng chứa mật khẩu hiện tại của người dùng hiện tại, được điền trước bằng thông tin nhập ẩn.

Để giải lab, lấy lại mật khẩu của administrator, sau đó dùng nó để xóa người dùng carlos.

Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter

ACCESS THE LAB

Solution

Login vào bằng tài khoản được cung cấp, thay đổi user id trên url thành administrator

Tại mục password mở inspect lên và nhìn thấy cái value của nó chính là mật khẩu của administrator, copy và login vào tài khoản administrator và truy cập admin panel xoá user carlos đi thôi

Insecure direct object references (IDOR)

Trong phần này, chúng tôi sẽ giải thích tham chiếu đối tượng trực tiếp không an toàn (IDOR) là gì và mô tả một số lỗ hổng phổ biến.

What are insecure direct object references (IDOR)?

Tham chiếu đối tượng trực tiếp không an toàn (IDOR) là một loại lỗ hổng kiểm soát quyền truy cập phát sinh khi ứng dụng sử dụng thông tin đầu vào do người dùng cung cấp để truy cập trực tiếp vào đối tượng. Thuật ngữ IDOR đã được phổ biến rộng rãi nhờ sự xuất hiện của nó trong Top Ten của OWASP 2007. Tuy nhiên, đây chỉ là một ví dụ trong số nhiều lỗi triển khai kiểm soát quyền truy cập có thể dẫn đến việc kiểm soát quyền truy cập bị phá vỡ. Các lỗ hổng IDOR thường liên quan nhất đến việc leo thang đặc quyền theo chiều ngang, nhưng chúng cũng có thể phát sinh liên quan đến việc leo thang đặc quyền theo chiều dọc.

IDOR examples

Có nhiều ví dụ về lỗ hổng kiểm soát truy cập trong đó các giá trị tham số do người dùng kiểm soát được sử dụng để truy cập trực tiếp vào tài nguyên hoặc chức năng.

IDOR vulnerability with direct reference to database objects

Hãy xem xét một trang web sử dụng URL sau để truy cập trang tài khoản khách hàng bằng cách truy xuất thông tin từ cơ sở dữ liệu phụ trợ:

https://insecure-website.com/customer_account?customer_number=132355

Ở đây, mã số khách hàng được sử dụng trực tiếp làm chỉ mục bản ghi trong các truy vấn được thực hiện trên cơ sở dữ liệu phía sau. Nếu không có biện pháp kiểm soát nào khác, kẻ tấn công có thể chỉ cần sửa đổi giá trị customer_number , bỏ qua kiểm soát truy cập để xem hồ sơ của khách hàng khác. Đây là một ví dụ về lỗ hổng IDOR dẫn đến leo thang đặc quyền theo chiều ngang.

Kẻ tấn công có thể thực hiện leo thang đặc quyền theo chiều ngang và chiều dọc bằng cách thay đổi người dùng thành người dùng có các đặc quyền bổ sung trong khi bỏ qua các biện pháp kiểm soát truy cập. Ví dụ: các khả năng khác bao gồm khai thác rò rỉ mật khẩu hoặc sửa đổi các tham số khi kẻ tấn công đã truy cập vào trang tài khoản của người dùng.

IDOR vulnerability with direct reference to static files

Lỗ hổng IDOR thường phát sinh khi các tài nguyên nhạy cảm nằm trong các tệp tĩnh trên hệ thống tệp phía máy chủ. Ví dụ: một trang web có thể lưu bản ghi tin nhắn trò chuyện vào đĩa bằng cách sử dụng tên tệp tăng dần và cho phép người dùng truy xuất những bản ghi này bằng cách truy cập một URL như sau:

https://insecure-website.com/static/12144.txt

Trong tình huống này, kẻ tấn công có thể chỉ cần sửa đổi tên tệp để truy xuất bản ghi do người dùng khác tạo và có khả năng lấy được thông tin xác thực của người dùng cũng như dữ liệu nhạy cảm khác.

Lab: Insecure direct object references

Lab này lưu trữ nhật ký trò chuyện của người dùng trực tiếp trên hệ thống tệp của máy chủ và truy xuất chúng bằng URL tĩnh.

Giải quyết lab bằng cách tìm mật khẩu cho người dùng carlos, và đăng nhập vào tài khoản của họ.

ACCESS THE LAB

Solution

Mở sang tab live chat nghịch thử 1 tí. Ấn vào View transcript thì thấy tải file 2.txt về máy, xem log và chuyển nó sang Repeater

Thử sửa lại thành 1.txt và sẽ thấy được lịch sử chat và có password

Đăng nhập vào tài khoản carlos và mật khẩu đó thôi

Access control vulnerabilities in multi-step processes

Nhiều trang web triển khai các chức năng quan trọng qua một loạt các bước. Điều này phổ biến khi:

• Cần phải nắm bắt được nhiều đầu vào hoặc tùy chọn khác nhau.
• Người dùng cần xem xét và xác nhận chi tiết trước khi thực hiện hành động.

Ví dụ: chức năng quản trị để cập nhật thông tin người dùng có thể bao gồm các bước sau:

1. Tải biểu mẫu chứa thông tin chi tiết về một người dùng cụ thể.
2. Gửi các thay đổi.
3. Xem lại các thay đổi và xác nhận.

Đôi khi, một trang web sẽ triển khai các biện pháp kiểm soát truy cập nghiêm ngặt đối với một số bước này nhưng lại bỏ qua các bước khác. Hãy tưởng tượng một trang web nơi các biện pháp kiểm soát truy cập được áp dụng chính xác cho bước đầu tiên và bước thứ hai, nhưng không áp dụng được cho bước thứ ba. Trang web giả định rằng người dùng sẽ chỉ đạt đến bước 3 nếu họ đã hoàn thành các bước đầu tiên được kiểm soát đúng cách. Kẻ tấn công có thể truy cập trái phép vào chức năng bằng cách bỏ qua hai bước đầu tiên và trực tiếp gửi yêu cầu cho bước thứ ba với các tham số được yêu cầu.

Lab: Multi-step process with no access control on one step

Lab này có bảng quản trị với quy trình gồm nhiều bước chưa hoàn thiện để thay đổi vai trò của người dùng. Bạn có thể làm quen với bảng quản trị bằng cách đăng nhập bằng thông tin đăng nhập administrator:admin.

Để giải quyết lab, hãy đăng nhập bằng thông tin đăng nhập wiener:peter và khai thác các biện pháp kiểm soát truy cập còn thiếu sót để thăng tiến trở thành quản trị viên.

ACCESS THE LAB

Solution

Login vào tài khoản administrator để tìm hiểu một chút về admin panel

Ấn upgrade carlos và nhìn request sẽ thấy gửi lên 2 param là username=carlos&action=upgrade trả về 1 form xác nhận, nếu nhấn có sẽ gửi lại request này một lần nữa kèm thêm 1 param là confirmed=true.

nếu nhấn quay lại sẽ chỉ load lại trang admin panel thôi.

Cho request vào Repeater và đăng nhập vào tài khoản wiener, copy session cookie của wiener thay vào trong request của admin mình vừa thêm vào trong Repeater để test

Thay username là wiener để nâng cấp tài khoản lên 

Không có quyền làm thế là đương nhiên, giờ thử thêm confirmed=true vào param và xem xét tiếp

Vậy là đã vượt qua. Mình cũng chưa hình dung được liệu trong thực tế có ai còn có thể code bug được thế này không nhưng chắc chỉ mang tính chất giới thiệu trong lab này thôi, với lại giờ toàn thấy sử dụng jwt nên trước khi chạy được đến function upgrade này thì đã biết được có phải là tài khoản hợp lệ hay không rồi.

Referer-based access control

Một số trang web kiểm soát quyền truy cập dựa trên header Referer được gửi trong yêu cầu HTTP. Header Referer có thể được thêm vào yêu cầu của trình duyệt để cho biết trang nào đã bắt đầu yêu cầu.

Ví dụ: một ứng dụng thực thi quyền kiểm soát quyền truy cập đối với trang quản trị chính tại /admin, nhưng đối với các trang phụ như /admin/deleteUser chỉ kiểm tra header Referer. Nếu header Referer chứa URL chính /admin thì yêu cầu sẽ được cho phép.

Trong trường hợp này, kẻ tấn công có thể hoàn toàn kiểm soát Referer header. Điều này có nghĩa là họ có thể giả mạo các yêu cầu trực tiếp đến các trang phụ nhạy cảm bằng cách cung cấp Referer header, và có được quyền truy cập trái phép.

Lab: Referer-based access control

Lab này kiểm soát quyền truy cập vào chức năng quản trị nhất định dựa trên Referer header. Bạn có thể làm quen với bảng quản trị bằng cách đăng nhập bằng thông tin đăng nhập administrator:admin.

Để hoàn thành lab, hãy đăng nhập bằng thông tin đăng nhập wiener:peter và khai thác các biện pháp kiểm soát truy cập còn thiếu sót để thăng tiến trở thành quản trị viên.

ACCESS THE LAB

Solution

Theo như yêu cầu của lab thì mình tập trung vào Referer header thôi. đăng nhập vào tài khoản admin và truy cập vào admin panel và nâng cấp tài khoản carlos lên admin

Nhưng khi mình thử hạ quyền xuống nhưng bỏ Referer header đi thì lại báo không có quyền truy cập mặc dù đó là tài khoản administrator -.-

Sửa lại và giờ login vào tài khoản wiener để nâng cấp tài khoản winer lên admin

Chỉ cần thay session và username là thành công

Location-based access control

Một số trang web thực thi các biện pháp kiểm soát truy cập dựa trên vị trí địa lý của người dùng. Ví dụ: điều này có thể áp dụng cho các ứng dụng ngân hàng hoặc dịch vụ truyền thông nơi áp dụng luật pháp của tiểu bang hoặc các hạn chế kinh doanh. Các biện pháp kiểm soát truy cập này thường có thể bị phá vỡ bằng cách sử dụng proxy web, VPN hoặc thao túng cơ chế định vị địa lý phía máy khách.

How to prevent access control vulnerabilities

Các lỗ hổng kiểm soát truy cập có thể được ngăn chặn bằng cách áp dụng phương pháp phòng thủ chuyên sâu và áp dụng các nguyên tắc sau:

• Không bao giờ nên phụ thuộc chỉ vào sự làm rối mã để kiểm soát quyền truy cập.
• Trừ khi một tài nguyên được dự định để có thể truy cập công khai, nên từ chối quyền truy cập theo mặc định.
• Ở mức ứng dụng, hãy sử dụng một cơ chế duy nhất trên toàn ứng dụng để áp đặt kiểm soát quyền truy cập.
• Ở mức mã nguồn, làm cho việc khai báo quyền truy cập cho mỗi tài nguyên trở thành bắt buộc đối với các nhà phát triển, và từ chối quyền truy cập theo mặc định.
• Thực hiện kiểm tra và đánh giá kỹ lưỡng kiểm soát quyền truy cập để đảm bảo chúng hoạt động theo thiết kế.