Access Control
Last updated
Last updated
Kiểm soát truy cập là việc áp dụng các ràng buộc với đối tượng (user, group, ...) để được phép thực hiện hành động hoặc truy cập tài nguyên nào đó. Trong các ứng dụng web, kiểm soát truy cập phụ thuộc vào xác thực và quản lý phiên:
Xác thực xác nhận người dùng chính là người mà họ khai báo.
Quản lý phiên xác định những yêu cầu HTTP tiếp theo nào đang được thực hiện bởi cùng một người dùng.
Kiểm soát truy cập 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.
Broken access control rất phổ biến và thường gây ra lỗ hổng bảo mật nghiêm trọng. Thiết kế và quản lý kiểm soát truy cập là vấn đề phức tạp, áp dụng các ràng buộc về mặt kinh doanh, tổ chức và pháp lý vào việc triển khai kỹ thuật, và là do con người đưa ra nên khả năng xảy ra lỗi là rất cao.
Cơ chế hạn chế quyền truy cập vào các chức năng nhạy cảm đối với từng loại người dùng cụ thể (các loại người dùng khác nhau có thể truy cập vào các chức năng ứng dụng khác nhau)
Ví dụ, người quản trị 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.
Các biện pháp kiểm soát truy cập theo chiều dọc có thể là các triển khai chi tiết hơn của các mô hình bảo mật được thiết kế để thực thi các chính sách kinh doanh như phân tách nhiệm vụ và đặc quyền tối thiểu.
Cơ chế hạn chế quyền truy cập vào tài nguyên cho những người dùng cụ thể (những người dùng khác nhau có thể 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 họ, nhưng không phải tài khoản của bất kỳ người dùng nào khác.
Kiểm soát truy cập theo 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 tương tác của người dùng với ứng dụng.
Kiểm soát truy cập theo ngữ cảnh ngăn người dùng thực hiện hành động theo thứ tự sai.
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.
Nếu người dùng có thể 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 là quản trị viên có thể 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.
Về cơ bản nhất, leo thang đặc quyền theo chiều dọc phát sinh khi một ứng dụng không thực thi bất kỳ biện pháp bảo vệ nào cho chức năng nhạy cảm.
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
Điều này có thể được truy cập bởi bất kỳ người dùng nào. Trong một số trường hợp, URL quản trị có thể được tiết lộ ở các vị trí khác, chẳng hạn như tệp 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 wordlist để tìm ra vị trí của chức năng nhạy cảm.
Trong một số trường hợp, chức năng nhạy cảm được che giấu bằng cách cung cấp cho nó một URL ít dự đoán hơn.
https://insecure-website.com/administrator-panel-yb556
Kẻ tấn công có thể không đoán được trực tiếp điều này. 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ộ trong JavaScript xây dựng giao diện người dùng với tất cả người dùng bất kể vai trò của họ:
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. Có thể là
Một trường ẩn.
Một cookie.
Một tham số chuỗi truy vấn được đặt sẵ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à truy cập vào chức năng mà họ không được phép, chẳng hạn như chức năng quản trị.
Một số ứng dụng thực thi kiểm soát truy cập ở lớp nền tảng. Chúng 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ụ:
DENY: POST, /admin/deleteUser, managers
DENY phương thức POST trên URL /admin/deleteUserđối với người dùng trong nhóm managers,
Một số framework hỗ trợ HTTP header không chuẩn có thể được dùng để ghi đè URl trong request gốc, như X-Original-URLvà X-Rewrite-URL. Nếu một trang web sử dụng các 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 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
...
Một số trang web chấp nhận các phương thức yêu cầu HTTP khác nhau khi thực hiện một hành động. Nếu kẻ tấn công có thể sử dụng GETmethod(hoặc method) để thực hiện các hành động trên một URL bị hạn chế, chúng có thể bỏ qua quyền kiểm soát truy cập được triển khai ở plaffom layer.
Một số trang web có thể xử lý các yêu cầu đến endpoint một cách không nghiêm ngặt. Ví dụ, chúng có thể bỏ qua sự khác biệt về chữ hoa và chữ thường, do đó yêu cầu tới /ADMIN/DELETEUSER vẫn có thể được ánh xạ tới endpoint /admin/deleteUser và nếu cơ chế kiểm soát truy cập không linh hoạt, nó có thể coi đây là hai endpoint khác nhau và không thực thi các hạn chế đúng cách.
Những sự không nhất quán tương tự có thể xảy ra sử dụng framework Spring và bật tùy chọn useSuffixPatternMatch. Tùy chọn này cho phép ánh xạ các đường dẫn với phần mở rộng tệp bất kỳ tới endpoint tương đương không có phần mở rộng. Ví dụ, một yêu cầu tới /admin/deleteUser.anything vẫn có thể khớp với mẫu /admin/deleteUser. Trước phiên bản Spring 5.3, tùy chọn này được bật mặc định.
Trên các hệ thống khác, bạn có thể gặp sự khác biệt trong cách xử lý endpoint với hoặc không có dấu gạch chéo / ở cuối. Trong trường hợp này, bạn có thể lợi dụng điều này để bỏ qua kiểm soát truy cập bằng cách thêm một dấu gạch chéo vào đường dẫn, như /admin/deleteUser/.
Sự leo thang đặc quyền theo chiều ngang xảy ra nếu người dùng có thể truy cập vào các tài nguyên thuộc về người dùng khác, thay vì tài nguyên của riêng họ cùng loại. 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 riêng 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 riêng họ bằng URL sau:
https://insecure-website.com/myaccount?id=123
Nếu kẻ tấn công sửa đổi idgiá trị tham số thành giá trị của người dùng khác, chúng có thể truy cập vào trang tài khoản của người dùng đó cũng như dữ liệu và chức năng liên quan. Đây là ví dụ về lỗ hổng tham chiếu đối tượng trực tiếp không an toàn ().
Trong một số ứng dụng, tham số có thể khai thác có giá trị khó dự đoán được như globally unique identifiers (GUIDs) để xác định người dùng. Điều này có thể ngăn chặ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, các 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, chẳng hạn như tin nhắn hoặc đánh giá của người dùng.
Trong một số trường hợp, ứng dụng phát hiện khi người dùng không được phép truy cập tài nguyên và trả về chuyển hướng đến trang đăng nhập. Tuy nhiên, phản hồi chứa chuyển hướng vẫn có thể bao gồm một số dữ liệu nhạy cảm thuộc về người dùng mục tiêu, do đó cuộc tấn công vẫn thành công.
Tham chiếu đối tượng trực tiếp không an toàn (IDOR) là một tiểu thể loại của lỗ hổng kiểm soát truy cập. IDOR xảy ra nếu một ứng dụng sử dụng dữ liệu đầu vào do người dùng cung cấp để truy cập trực tiếp vào các đối tượng và kẻ tấn công có thể sửa đổi dữ liệu đầu vào để có được quyền truy cập trái phép. Nó đã trở nên phổ biến khi xuất hiện trong Top Ten của OWASP 2007. Đây chỉ là một ví dụ về nhiều lỗi triển khai có thể cung cấp phương tiện để vượt qua các biện pháp kiểm soát truy cập.
Nhiều trang web thực hiện 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 thu thập nhiều đầu vào hoặc tùy chọn khác nhau.
Người dùng cần xem lại và xác nhận thông tin 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:
Tải biểu mẫu chứa thông tin chi tiết của một người dùng cụ thể.
Gửi các thay đổi.
Xem lại và xác nhận các thay đổi.
Đôi khi, một trang web sẽ thực hiện kiểm soát truy cập nghiêm ngặt ở một số bước nhưng lại bỏ qua các bước khác. Hãy tưởng tượng một trang web mà việc kiểm soát truy cập được áp dụng đúng cách cho bước đầu tiên và bước thứ hai, nhưng không áp dụng cho bước thứ ba. Trang web giả định rằng người dùng chỉ có thể đến bước 3 nếu họ đã hoàn thành các bước đầu tiên, vốn đã được kiểm soát đúng cách. Kẻ tấn công có thể truy cập trái phép chức năng này 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ần thiết.
Một số trang web kiểm soát truy cập dựa trên Referer header. Referer header có thể được thêm vào requests bởi browsers để chỉ ra trang nào đã khởi tạo request.
Ví dụ: Một ứng dụng đã triển khai kiểm soát truy cập rất chặt chẽ với rang quản trị chính tại /admin, nhưng đối với các trang phụ như /admin/deleteUserchỉ kiểm tra Referer header. Nếu Referer header chứa/admin URL, request được cho phép.
Trong trường hợp này, dù không thể truy cập vào /admin kẻ tấn công có thể tạo ra 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 cần thiết và có được quyền truy cập trái phép.
Một số trang web thực thi 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 luật pháp tiểu bang hoặc hạn chế kinh doanh áp dụng. Các kiểm soát truy cập này thường có thể bị bỏ qua bằng cách sử dụng proxy web, VPN hoặc thao tác các cơ chế định vị địa lý phía máy khách.
Không bao giờ chỉ dựa vào phương pháp che giấu để kiểm soát truy cập.
Trừ khi tài nguyên được thiết kế để công khai, hãy từ chối quyền truy cập theo mặc định.
Bất cứ khi nào có thể, hãy sử dụng một cơ chế duy nhất trên toàn ứng dụng để thực thi kiểm soát truy cập.
Ở cấp độ mã nguồn, hãy bắt buộc các nhà phát triển phải khai báo quyền truy cập được phép cho từng tài nguyên và từ chối quyền truy cập theo mặc định.
Kiểm tra và thử nghiệm kỹ lưỡng các biện pháp kiểm soát truy cập để đảm bảo chúng hoạt động như thiết kế.
