Loại kiểm tra này tập trung vào việc xác minh cách lược đồ ủy quyền đã được triển khai cho từng vai trò hoặc đặc quyền để có quyền truy cập vào các chức năng và tài nguyên dành riêng.
Các bài viết liên quan:
Đối với mọi vai trò cụ thể mà người kiểm tra nắm giữ trong quá trình đánh giá và đối với mọi chức năng và yêu cầu mà ứng dụng thực thi trong giai đoạn hậu xác thực, cần phải xác minh:
- Có thể truy cập tài nguyên đó ngay cả khi người dùng không được xác thực?
- Có thể truy cập tài nguyên đó sau khi đăng xuất không?
- Có thể truy cập các chức năng và tài nguyên mà người dùng có vai trò hoặc đặc quyền khác có thể truy cập được không?
Cố gắng truy cập ứng dụng với tư cách người dùng quản trị và theo dõi tất cả các chức năng quản trị.
Có thể truy cập các chức năng quản trị nếu người kiểm tra đăng nhập với tư cách là người dùng không phải quản trị viên không?
Có thể sử dụng các chức năng quản trị này với tư cách là người dùng với vai trò khác và hành động đó nên bị từ chối cho ai không?
Mục tiêu kiểm tra Bypassing Authorization Schema
Đánh giá xem có thể truy cập theo chiều ngang hoặc chiều dọc hay không.
Làm thế nào để kiểm tra Bypassing Authorization Schema
- Truy cập tài nguyên và tiến hành horizontal Bypassing Authorization Schema.
- Truy cập tài nguyên và tiến hành Vertical Bypassing Authorization Schema.
Kiểm tra lỗ hổng Horizontal Bypassing Authorization Schema
Đối với mọi chức năng, vai trò cụ thể hoặc yêu cầu mà ứng dụng thực thi, cần phải xác minh:
- Có thể truy cập các tài nguyên mà người dùng có danh tính khác có cùng vai trò hoặc đặc quyền có thể truy cập được không?
- Có thể vận hành các chức năng trên các tài nguyên mà người dùng có danh tính khác có thể truy cập được không?
Đối với mỗi vai trò:
- Đăng ký hoặc tạo hai người dùng có đặc quyền giống hệt nhau.
- Thiết lập và duy trì hai phiên hoạt động khác nhau (một phiên cho mỗi người dùng).
- Đối với mọi yêu cầu, hãy thay đổi các thông số liên quan và mã định danh phiên từ mã thông báo một sang mã thông báo hai và chẩn đoán phản hồi cho từng mã thông báo.
- Một ứng dụng sẽ bị coi là dễ bị tấn công nếu các phản hồi giống nhau, chứa cùng dữ liệu riêng tư hoặc cho biết hoạt động thành công trên tài nguyên hoặc dữ liệu của người dùng khác.
Ví dụ: giả sử rằng chức năng viewSettings là một phần của mọi menu tài khoản của ứng dụng có cùng vai trò và có thể truy cập nó bằng cách yêu cầu URL sau: https://www.example.com/account/viewSettings. Sau đó, yêu cầu HTTP sau được tạo khi gọi hàm viewSettings:
POST /account/viewSettings HTTP/1.1 Host: www.example.com [other HTTP headers] Cookie: SessionID=USER_SESSION username=example_user
Phản hồi hợp lệ và hợp pháp:
HTTP1.1 200 OK
[other HTTP headers]
{
"username": "example_user",
"email": "example@email.com",
"address": "Example Address"
}Kẻ tấn công có thể thử và thực hiện yêu cầu đó với cùng một tham số tên người dùng:
POST /account/viewCCpincode HTTP/1.1 Host: www.example.com [other HTTP headers] Cookie: SessionID=ATTACKER_SESSION username=example_user
Nếu phản hồi của kẻ tấn công chứa dữ liệu của example_user thì ứng dụng sẽ dễ bị tấn công theo chuyển động ngang, nơi người dùng có thể đọc hoặc ghi dữ liệu của người dùng khác.
Kiểm tra lỗ hổng Vertical Bypassing Authorization Schema
Bỏ qua ủy quyền theo chiều dọc dành riêng cho trường hợp kẻ tấn công có được vai trò cao hơn vai trò của chúng. Kiểm tra cho việc bỏ qua này tập trung vào việc xác minh cách thực hiện lược đồ ủy quyền theo chiều dọc cho từng vai trò. Đối với mọi chức năng, trang, vai trò cụ thể hoặc yêu cầu mà ứng dụng thực thi, cần phải xác minh xem có thể:
Truy cập các tài nguyên mà chỉ người dùng có vai trò cao hơn mới có thể truy cập được.
Vận hành các chức năng trên các tài nguyên chỉ được hoạt động bởi người dùng có danh tính vai trò cao hơn hoặc cụ thể.
Đối với mỗi vai trò:
- Đăng ký một người dùng.
- Thiết lập và duy trì hai phiên khác nhau dựa trên hai vai trò khác nhau.
- Đối với mọi yêu cầu, hãy thay đổi số nhận dạng phiên từ mã gốc sang số nhận dạng phiên của vai trò khác và đánh giá phản hồi cho từng yêu cầu.
- Một ứng dụng sẽ bị coi là dễ bị tấn công nếu phiên đặc quyền yếu hơn chứa cùng dữ liệu hoặc chỉ ra các hoạt động thành công trên các chức năng đặc quyền cao hơn.
Banking Site Roles Scenario
Bảng sau đây minh họa các vai trò của hệ thống trên một trang web ngân hàng. Mỗi vai trò liên kết với các quyền cụ thể cho chức năng menu sự kiện:
Ứng dụng sẽ được coi là dễ bị tấn công nếu:
- Khách hàng có thể vận hành các chức năng quản trị viên, quản lý hoặc nhân viên;
- Người dùng nhân viên có thể vận hành các chức năng quản lý hoặc quản trị viên;
- Người quản lý có thể vận hành các chức năng của quản trị viên.
Giả sử rằng chức năng deleteEvent là một phần của menu tài khoản quản trị viên của ứng dụng và có thể truy cập nó bằng cách yêu cầu URL sau: https://www.example.com/account/deleteEvent. Sau đó, yêu cầu HTTP sau được tạo khi gọi hàm deleteEvent:
POST /account/deleteEvent HTTP/1.1 Host: www.example.com [other HTTP headers] Cookie: SessionID=ADMINISTRATOR_USER_SESSION EventID=1000001
Câu trả lời hợp lệ:
HTTP/1.1 200 OK
[other HTTP headers]
{"message": "Event was deleted"}Kẻ tấn công có thể thử và thực hiện cùng một yêu cầu:
POST /account/deleteEvent HTTP/1.1 Host: www.example.com [other HTTP headers] Cookie: SessionID=CUSTOMER_USER_SESSION EventID=1000002
Nếu phản hồi yêu cầu của kẻ tấn công chứa cùng dữ liệu {“message”: “Event was deleted”} thì ứng dụng sẽ dễ bị tấn công.
Quyền truy cập trang của quản trị viên
Giả sử rằng menu quản trị viên là một phần của tài khoản quản trị viên.
Ứng dụng sẽ được coi là dễ bị tấn công nếu bất kỳ vai trò nào khác ngoài quản trị viên có thể truy cập menu quản trị viên. Đôi khi, các nhà phát triển chỉ thực hiện xác thực ủy quyền ở cấp GUI và để lại các chức năng mà không xác thực ủy quyền, do đó có khả năng dẫn đến lỗ hổng.
Kiểm tra quyền truy cập vào các chức năng quản trị
Ví dụ: giả sử rằng chức năng addUser là một phần của menu quản trị của ứng dụng và có thể truy cập nó bằng cách yêu cầu URL sau https://www.example.com/admin/addUser.
Sau đó, yêu cầu HTTP sau được tạo khi gọi hàm addUser:
POST /admin/addUser HTTP/1.1 Host: www.example.com [...] userID=fakeuser&role=3&group=grp001
Các câu hỏi hoặc cân nhắc khác sẽ diễn ra theo hướng sau:
- Điều gì xảy ra nếu một người dùng không phải là quản trị viên cố gắng thực hiện yêu cầu đó?
- Người dùng sẽ được tạo?
- Nếu vậy, người dùng mới có thể sử dụng các đặc quyền của họ không?
Kiểm tra quyền truy cập vào các tài nguyên được giao cho một vai trò khác
Các ứng dụng khác nhau kiểm soát tài nguyên thiết lập dựa trên vai trò của người dùng. Hãy lấy ví dụ về sơ yếu lý lịch hoặc CV (sơ yếu lý lịch) được tải lên biểu mẫu nghề nghiệp vào nhóm S3.
Là một người dùng bình thường, hãy thử truy cập vào vị trí của các tệp đó. Nếu bạn có thể truy xuất, sửa đổi hoặc xóa chúng, thì ứng dụng sẽ dễ bị tấn công.
Kiểm tra để xử lý tiêu đề yêu cầu đặc biệt
Một số ứng dụng hỗ trợ các tiêu đề không chuẩn như X-Original-URL hoặc X-Rewrite-URL để cho phép ghi đè URL mục tiêu trong các yêu cầu với URL được chỉ định trong giá trị tiêu đề.
Hành vi này có thể được tận dụng trong tình huống ứng dụng đứng sau một thành phần áp dụng hạn chế kiểm soát truy cập dựa trên URL yêu cầu.
Ví dụ: loại hạn chế kiểm soát truy cập dựa trên URL yêu cầu có thể là chặn truy cập từ Internet vào bảng điều khiển quản trị được hiển thị trên / console hoặc / admin.
Để phát hiện hỗ trợ cho tiêu đề X-Original-URL hoặc X-Rewrite-URL, có thể áp dụng các bước sau.
- Gửi một yêu cầu bình thường mà không có bất kỳ tiêu đề X-Original-Url hoặc X-Rewrite-Url nào
GET / HTTP/1.1 Host: www.example.com [...]
- Gửi yêu cầu với tiêu đề X-Original-Url trỏ đến tài nguyên không tồn tại
GET / HTTP/1.1 Host: www.example.com X-Original-URL: /donotexist1 [...]
- Gửi yêu cầu với tiêu đề X-Rewrite-Url trỏ đến tài nguyên không tồn tại
GET / HTTP/1.1 Host: www.example.com X-Rewrite-URL: /donotexist2 [...]
Nếu phản hồi cho một trong hai yêu cầu chứa các điểm đánh dấu mà tài nguyên không được tìm thấy, điều này chỉ ra rằng ứng dụng hỗ trợ các tiêu đề yêu cầu đặc biệt. Các điểm đánh dấu này có thể bao gồm mã trạng thái phản hồi HTTP 404 hoặc thông báo “không tìm thấy tài nguyên” trong nội dung phản hồi.
Sau khi hỗ trợ cho tiêu đề X-Original-URL hoặc X-Rewrite-URL đã được xác thực thì dự kiến bỏ qua hạn chế kiểm soát truy cập có thể được tận dụng bằng cách gửi yêu cầu dự kiến tới ứng dụng nhưng chỉ định một URL “được phép” ở phía trước -end thành phần làm URL yêu cầu chính và chỉ định URL đích thực trong tiêu đề X-Original-URL hoặc X-Rewrite-URL tùy thuộc vào URL được hỗ trợ. Nếu cả hai đều được hỗ trợ thì hãy thử lần lượt để xác minh tiêu đề nào mà bỏ qua là hiệu quả.
- Các tiêu đề khác cần xem xét
Thường thì các bảng quản trị hoặc các bit chức năng liên quan đến quản trị chỉ có thể truy cập được đối với các máy khách trên mạng cục bộ, do đó có thể lạm dụng các tiêu đề HTTP liên quan đến proxy hoặc chuyển tiếp khác nhau để có được quyền truy cập. Một số tiêu đề và giá trị cần kiểm tra là:
Headers: X-Forwarded-For X-Forward-For X-Remote-IP X-Originating-IP X-Remote-Addr X-Client-IP Values 127.0.0.1 (or anything in the 127.0.0.0/8 or ::1/128 address spaces) localhost Any RFC1918 address: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Link local addresses: 169.254.0.0/16
Lưu ý: Bao gồm một phần tử cổng cùng với địa chỉ hoặc tên máy chủ cũng có thể giúp bỏ qua các biện pháp bảo vệ biên như tường lửa ứng dụng web, v.v. Ví dụ: 127.0.0.4:80, 127.0.0.4:443, 127.0.0.4:43982
Biện pháp khắc phục hậu quả Bypassing Authorization Schema
Áp dụng các nguyên tắc đặc quyền ít nhất đối với người dùng, vai trò và tài nguyên để đảm bảo rằng không có truy cập trái phép nào xảy ra.
