6.1. Hiểu các yêu cầu kiểm soát truy cập
Dựa trên chức năng cốt lõi được triển khai trong ứng dụng, hiểu các yêu cầu đối với kiểm soát truy cập theo chiều dọc (các cấp độ người dùng khác nhau có quyền truy cập vào các loại chức năng khác nhau) và theo chiều ngang (người dùng ở cùng cấp đặc quyền có quyền truy cập đến các tập hợp con dữ liệu khác nhau). Thông thường, cả hai kiểu phân ly đều có mặt. Ví dụ: người dùng bình thường có thể truy cập dữ liệu của riêng họ, trong khi quản trị viên có thể truy cập dữ liệu của mọi người.
Xác định các vùng chức năng và loại tài nguyên có ích cho tấn công leo thang đặc quyền bằng cách kiểm tra lại kết quả ánh xạ ứng dụng.
Để thực hiện kiểm tra hiệu quả các lỗ hổng kiểm soát truy cập, điều kiện lý tưởng nhất là có được các tài khoản với các đặc quyền khác nhau. Để có được các tài khoản có đặc quyền theo chiều ngang, có thể đăng ký nhưng để có được tài khoản có đặc
quyền theo chiều dọc cần có sự chấp thuận của chủ sở hữu hoặc cần khai thác một số lỗ hổng để có được quyền truy cập vào tài khoản có đặc quyền cao. Tính khả dụng của các tài khoản khác nhau sẽ ảnh hưởng đến các loại thử nghiệm có thể thực hiện (sẽ được mô tả sau).
6.2. Kiểm tra nhiều tài khoản
Nếu ứng dụng thực thi kiểm soát truy cập theo chiều dọc, trước tiên hãy sử dụng một tài khoản có đặc quyền cao để xác định tất cả các chức năng mà ứng dụng có thể truy cập. Sau đó, sử dụng tài khoản ít đặc quyền hơn và cố gắng truy cập từng mục của chức năng này.
- Sử dụng Burp xác định tất cả chức năng ứng dụng trong ngữ cảnh người dùng.
- Kiểm tra lại sơ đồ chức năng trang web, đảm bảo xác định đầy đủ chức năng trang web. Đăng xuất khỏi ứng dụng và đăng nhập lại với vai trò của người dùng khác. Sử dụng sơ đồ nội dung chọn tính năng “compare site maps” để xác định người dùng có đặc quyền thấp có thể truy cập được những chức năng đặc quyền cao nào (xem chương 8).
Nếu ứng dụng kiểm soát truy cập theo chiều ngang, thực hiện kiểm tra tương đương bằng cách sử dụng hai tài khoản cùng cấp đặc quyền và thử dùng một tài khoản để truy cập thông tin tài khoản kia. Việc này có thể thực hiện bằng cách thay đổi id người dùng (hoặc ID tài liệu) trong một request đến tài nguyên của người dùng khác.
Thực hiện kiểm tra thủ công các khóa của logic kiểm soát truy cập.
- Đối với mỗi đặc quyền của người dùng, kiểm tra các tài nguyên có sẵn. Thử truy cập trái phép bằng cách phát lại request sử dụng token của người dùng đó.
Thực hiện kiểm tra từng bước của các chức năng nhiều tầng riêng lẻ để đảm bảo kiểm soát truy cập được triển khai đúng cách ở mỗi giai đoạn, hoặc liệu ứng dụng có giả định rằng người dùng vào được giai đoạn sau đã vượt qua các kiểm tra được thực hiện trước đó. Ví dụ: nếu trang quản trị chứa form, hãy kiểm tra xem việc gửi form có được kiểm soát truy cập đúng không? Trong một số trường hợp các ứng dụng chỉ xác thực người dùng ở trang đăng nhập, có nghĩa là người dùng hoàn toàn có thể bỏ qua trang đăng nhập vào thẳng trang profile mà không cần xác thực lại.
6.3. Kiểm tra với quyền truy cập hạn chế
Nếu không có quyền truy cập trước vào các tài khoản ở các cấp đặc quyền khác nhau hoặc có quyền truy cập vào dữ liệu khác nhau, thì việc kiểm tra các kiểm soát truy cập trở nên khó khăn hơn. Nhiều lỗ hổng sẽ khó xác định hơn, bởi không biết tên của các URL, id và các tham số cần thiết để khai thác các điểm yếu.
Trong xác đinh sơ đồ các chức năng ứng dụng, sử dụng tài khoản có đặc quyền thấp, chúng ta có thể đã xác định được các chức năng đặc quyền như giao diện quản trị, có thể phán đoán được chúng không được bảo vệ đầy đủ.
Kiểm tra client và xác định các tham chiếu đến chức năng phía server.
Hầu hết dữ liệu chịu sự kiểm soát truy cập ngang được truy cập bằng cách sử dụng một id, chẳng hạn như số tài khoản hoặc tham chiếu đơn đặt hàng. Để kiểm tra xem các biện pháp kiểm
soát truy cập có hiệu quả khi chỉ sử dụng một tài khoản duy nhất hay không, phải cố gắng đoán hoặc xác định các id được liên kết với dữ liệu của người dùng khác. Nếu có thể, hãy tạo một loạt id (ví dụ: bằng cách tạo một số đơn đặt hàng mới). Cố gắng xác định các mẫu cho phép dự đoán id được cấp cho những người dùng khác. Nếu không có cách nào để tạo id mới, việc đoán hay xác định id sẽ trở nên khó khăn hơn.
Nếu có thể tìm ra cách đoán id của người dùng khác, sử dụng các kỹ thuật được mô tả trong chương 14 để thực hiện tấn công tự động nhằm thu thập dữ liệu của người dùng khác. Sử dụng chức năng Extract Grep trong Burp Intruder xác định các thông tin liên quan từ phản hồi của ứng dụng.
6.4. Kiểm tra các phương thức không an toàn
Một số ứng dụng triển khai kiểm soát truy cập theo các tham số cố định không an toàn. Kiểm tra các tham số như edit = false hoặc access = read trong các request, sửa đổi chúng để can thiệp vào logic kiểm soát truy cập của ứng dụng.
Một số ứng dụng kiểm soát truy cập dựa trên HTTP Referer header. Ví dụ: một ứng dụng có thể kiểm soát đúng quyền truy cập vào /admin.jsp và chấp nhận bất kỳ request có Referer là /admin.jsp. Để kiểm tra hành vi này, thực hiện một số hành động đặc quyền mà bạn được ủy quyền và gửi thiếu hoặc sửa Referer header. Nếu thay đổi này khiến ứng dụng chặn yêu cầu của bạn, nó có thể đang sử dụng Referer header không an toàn. Thử thực hiện hành động tương tự với người dùng đặc quyền thấp, nhưng có đủ Referer header xem liệu hành động này có thành công hay không.
Nếu ứng dụng cho phép phương thức HEAD hoạt động, kiểm tra khả năng kiểm soát truy cập vùng chứa URL không an toàn. Sử dụng các request với phương thức HEAD xem ứng dụng có cho phép hay không.