Phần này mô tả vấn đề leo thang đặc quyền từ giai đoạn này sang giai đoạn khác. Trong giai đoạn này, người thử nghiệm nên xác minh rằng người dùng không thể sửa đổi các đặc quyền hoặc vai trò của họ bên trong ứng dụng theo những cách có thể cho phép các cuộc tấn công leo thang đặc quyền.
Nâng cấp đặc quyền xảy ra khi người dùng có quyền truy cập vào nhiều tài nguyên hoặc chức năng hơn mức họ được phép bình thường và việc nâng cấp hoặc thay đổi như vậy phải được ứng dụng ngăn chặn. Điều này thường do một lỗ hổng trong ứng dụng gây ra. Kết quả là ứng dụng thực hiện các hành động với nhiều đặc quyền hơn so với dự định của nhà phát triển hoặc quản trị viên hệ thống.
Các bài viết liên quan:
Mức độ leo thang phụ thuộc vào những đặc quyền mà kẻ tấn công được phép sở hữu và những đặc quyền nào có thể nhận được khi khai thác thành công. Ví dụ: một lỗi lập trình cho phép người dùng có thêm đặc quyền sau khi xác thực thành công sẽ giới hạn mức độ leo thang, vì người dùng đã được ủy quyền để nắm giữ một số đặc quyền. Tương tự như vậy, kẻ tấn công từ xa giành được đặc quyền siêu người dùng mà không có bất kỳ xác thực nào sẽ có mức độ leo thang lớn hơn.
Thông thường, mọi người đề cập đến leo thang theo chiều dọc khi có thể truy cập tài nguyên được cấp cho các tài khoản đặc quyền hơn (ví dụ: có được đặc quyền quản trị cho ứng dụng) và leo thang theo chiều ngang khi có thể truy cập tài nguyên được cấp cho tài khoản được định cấu hình tương tự (ví dụ: trong một ứng dụng ngân hàng trực tuyến, truy cập thông tin liên quan đến một người dùng khác).
Mục tiêu kiểm tra Privilege Escalation
- Xác định các điểm tiêm liên quan đến thao tác đặc quyền.
- Fuzz hoặc cố gắng vượt qua các biện pháp bảo mật.
Làm thế nào để kiểm tra Privilege Escalation
Kiểm tra thao tác với vai trò / đặc quyền
Trong mọi phần của ứng dụng nơi người dùng có thể tạo thông tin trong cơ sở dữ liệu (ví dụ: thanh toán, thêm liên hệ hoặc gửi tin nhắn), có thể nhận thông tin (sao kê tài khoản, chi tiết đơn đặt hàng, v.v.) hoặc xóa thông tin (thả người dùng, tin nhắn, v.v.), cần phải ghi lại chức năng đó. Người thử nghiệm nên cố gắng truy cập các chức năng đó với tư cách là người dùng khác để xác minh xem có thể truy cập vào chức năng mà vai trò / đặc quyền của người dùng đó không cho phép hay không (nhưng có thể được cho phép với tư cách là người dùng khác).
Thao túng nhóm người dùng
Ví dụ: HTTP POST sau cho phép người dùng thuộc grp001 truy cập vào đơn đặt hàng # 0001:
POST /user/viewOrder.jsp HTTP/1.1 Host: www.example.com ... groupID=grp001&orderID=0001
Xác minh xem người dùng không thuộc grp001 có thể sửa đổi giá trị của tham số groupID và orderID để có quyền truy cập vào dữ liệu đặc quyền đó hay không.
Thao tác hồ sơ người dùng
Ví dụ: Câu trả lời của máy chủ sau đây hiển thị một trường ẩn trong HTML được trả lại cho người dùng sau khi xác thực thành công.
HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Wed, 1 Apr 2006 13:51:20 GMT Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com Cache-Control: no-cache Pragma: No-cache Content-length: 247 Content-Type: text/html Expires: Thu, 01 Jan 1970 00:00:00 GMT Connection: close <form name="autoriz" method="POST" action = "visual.jsp"> <input type="hidden" name="profile" value="SysAdmin">\ <body onload="document.forms.autoriz.submit()"> </td> </tr>
Điều gì sẽ xảy ra nếu người kiểm tra sửa đổi giá trị của cấu hình biến thành SysAdmin? Có thể trở thành quản trị viên không?
Thao túng giá trị điều kiện
Ví dụ: Trong môi trường mà máy chủ gửi thông báo lỗi được chứa dưới dạng giá trị trong một tham số cụ thể trong response, như sau:
@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar`0`0`0` StateExecToolBar`0`0`0`FlagsToolBar`0
Máy chủ cung cấp một sự tin tưởng ngầm cho người dùng. Nó tin rằng người dùng sẽ trả lời với thông báo trên khi kết thúc phiên.
Trong điều kiện này, hãy xác minh rằng không thể nâng cấp đặc quyền bằng cách sửa đổi các giá trị tham số. Trong ví dụ cụ thể này, bằng cách sửa đổi giá trị PVValid từ -1 thành 0 (không có điều kiện lỗi), có thể xác thực là quản trị viên cho máy chủ.
Thao tác địa chỉ IP
Một số trang web giới hạn quyền truy cập hoặc đếm số lần đăng nhập không thành công dựa trên địa chỉ IP.
Ví dụ:
X-Forwarded-For: 8.1.1.1
Trong trường hợp này, nếu trang web sử dụng giá trị của X-forwarded-For làm địa chỉ IP máy khách, người kiểm tra có thể thay đổi giá trị IP của tiêu đề X-forwarded-For HTTP để giải quyết vấn đề nhận dạng nguồn IP.
Truyền tải URL
Cố gắng xem qua trang web và kiểm tra xem một số trang có thể bỏ sót quá trình kiểm tra ủy quyền hay không.
Ví dụ:
/../.././userInfo.html
Whitebox
Nếu việc kiểm tra ủy quyền URL chỉ được thực hiện bằng cách đối sánh một phần URL, thì có khả năng người kiểm tra hoặc tin tặc có thể giải quyết vấn đề ủy quyền bằng kỹ thuật mã hóa URL.
Ví dụ:
startwith (), endwith (), chứa (), indexOf ()
SessionID yếu
ID phiên yếu có thuật toán có thể dễ bị tấn công brute Force. Ví dụ: một trang web đang sử dụng MD5 (Password + UserID) làm sessionID. Sau đó, người kiểm tra có thể đoán hoặc tạo sessionID cho những người dùng khác.
