Sinh viên năm cuối ngành An toàn thông tin tại Đại học FPT. Chuyên nghiên cứu khai thác lỗ hổng bảo mật Web, kiến trúc bảo mật AWS và các công cụ tự động hóa
Mục lụcMục lục
Web Security Iaw301 -
Bài viết này là một phần của loạt bài.
Kiểm soát truy cập là kiểm soát ai hay cái gì được quyền thực hiện một hành động hoặc truy cập một tài nguyên cụ thể.
Lỗ hổng kiểm soát truy cập là lỗi bảo mật cho phép người dùng không được ủy quyền được phép truy cập, chỉnh sửa, xóa bỏ dữ liệu mà họ đúng ra không được đụng đến.
Các loại kiểm soát truy cập phổ biến:
Discretionary Access Control (DAC): Kiểm soát dựa trên danh sách Access Control List (ACL). Owner của tài nguyên có toàn quyền quyết định ai được phép truy cập và được làm gì (Read, Write, Execute).
Mandatory Access Control (MAC): Mỗi người dùng được cấp một mức độ cho phép. Mỗi tài nguyên được gắn một nhãn bảo mật tương ứng. Người dùng chỉ được truy cập nếu mức độ cho phép của họ bằng hoặc cao hơn nhãn tài nguyên. Khác với DAC, người dùng không có quyền quyết định việc chia sẻ, hệ thống trung tâm sẽ áp đặt các quy tắc truy cập dựa trên “Nhãn bảo mật”.
Role-Based Access Control (RBAC): Nếu một nhân viên chuyển phòng ban, hệ thống chỉ cần thu hồi vai trò cũ và cấp vai trò mới, mọi quyền truy cập sẽ thay đổi theo. Đây là mô hình phổ biến trong các doanh nghiệp ngày nay. Quyền truy cập không được cấp cho từng cá nhân mà được gán vào các Roles.
Attribute-Based Access Control (ABAC): Hệ thống đánh giá các thuộc tính của Người dùng (phòng ban, chức vụ), Tài nguyên (loại dữ liệu, độ nhạy cảm), và Môi trường (thời gian truy cập, vị trí địa lý, địa chỉ IP).
Trong DBMS, các mô hình Access Control lan truyền từ cấp độ cấu trúc cao nhất (Instance/Database) xuống các phần tử nhỏ nhất (Table, Column, Row).
DAC: được thể hiện qua các lệnh DCL (Data Control Language). Người tạo ra table mặc định là chủ sở hữu và có quyền cấp phát cho người khác.
Cách lan truyền: sử dụng các lệnh GRANT hoặc REVOKE.
Ảnh hưởng đến dữ liệu:
Linh hoạt cao nhưng có rủi ro phân mảnh: Dữ liệu dễ dàng được chia sẻ giữa các nhóm làm việc. Tuy nhiên, nếu một user vô tình GRANT ALL cho tài khoản public, toàn bộ bảng dữ liệu đó có thể bị phơi bày.
Tác động của lỗ hổng: Nếu ứng dụng web bị dính lỗi SQL Injection và ứng dụng đó kết nối với database bằng một tài khoản có quá nhiều đặc quyền DAC (ví dụ tài khoản root), kẻ tấn công có thể dễ dàng dump (kéo) toàn bộ dữ liệu của hệ thống thay vì chỉ giới hạn ở bảng của một người dùng.
MAC: MAC trong database thường được triển khai dưới dạng Row-Level Security (RLS) hoặc tích hợp các nhãn bảo mật (như Oracle Label Security).
Cách lan truyền: Mỗi hàng trong database sẽ được gán thêm một cột ẩn chứa “Nhãn bảo mật”. Hệ thống quản trị sẽ tự động kiểm tra nhãn này với mức độ Clearance.
Ảnh hưởng dữ liệu:
Tính toàn vẹn tuyệt đối: Ngay cả DBA khi chạy lệnh SELECT * FROM Projects, DBMS sẽ tự động lọc và chỉ trả về những dữ liệu có nhãn bảo mật thấp hơn hoặc bằng với nhãn của DBA.
Chống rò rỉ dữ liệu: Hoàn toàn ngăn chặn việc dữ liệu nhạy cảm lan truyền ra khỏi vùng an toàn, nhưng đi kèm CPU overhead lớn khi truy vấn bảng có hàng triệu dòng.
RBAC: Mô hình tiêu chuẩn trong các DBMS hiện đại.
Cách lan truyền: Quản trị viên tạo ra các Roles như db_datareader, db_owner, db_datawriter để thêm các User vào.
Ảnh hưởng dữ liệu:
Quản lý vòng đời dữ liệu: Giúp tổ chức dễ dàng cấp quyền hàng loạt. Khi một kỹ sư chuyển dự án, hệ thống chỉ cần thay đổi Role, lập tức quyền Đọc/Ghi trên các Database liên quan bị cắt đứt, bảo vệ dữ liệu khỏi các rủi ro từ người dùng cũ.
Góc độ khai thác: Nếu hệ thống phân chia Role không chặt chẽ, kẻ tấn công sau khi thỏa hiệp được một tài khoản có Role thấp (như ReadOnly) có thể tìm cách khai thác các thủ tục lưu trữ (Stored Procedures) chạy bằng quyền của Role cao hơn để chiếm quyền kiểm soát toàn bộ Database.
ABAC: ABAC phát huy tối đa sức mạnh khi Database được đặt trên các hạ tầng Cloud. ABAC kiểm soát quyền truy cập dựa trên các siêu dữ liệu (Metadata) và trạng thái hiện tại.
Cách lan truyền: Các chính sách phân quyền (Policy) được viết dưới dạng JSON hoặc XML sẽ đánh giá các yêu cầu truy cập theo thời gian thực trước khi luồng dữ liệu chạm đến Database.
Ảnh hưởng dữ liệu:
Bảo vệ dữ liệu theo ngữ cảnh: Giúp dữ liệu an toàn trước các cuộc tấn công từ bên ngoài mạng nội bộ, ngăn chặn hành vi dump dữ liệu ngoài giờ làm việc, hoặc tự động chặn quyền truy cập vào các Clusters nếu thiết bị truy cập không vượt qua bài kiểm tra tình trạng bảo mật.
Tham chiếu đối tượng trực tiếp không an toàn (IDOR) là gì, và nó gây ra rủi ro bảo mật như thế nào trong các ứng dụng web?
Tham chiếu trực tiếp không an toàn (IDOR) là lỗ hổng cho phép người dùng truy cập trực tiếp vào môt đối tượng bằng cách truyền giá trị vào một tham số.
IDOR cho phép một người dùng bình thường có thể truy cập vào các dữ liệu nhạy cảm.
Kẻ tấn công có thể khai thác lỗ hổng IDOR trên một trang web như thế nào, và đâu là những kỹ thuật phổ biến được sử dụng trong các cuộc tấn công này?
Kẻ tấn công có thể khai thác lỗ hổng bằng cách truyền trực tiếp giá trị vào các tham số truy vấn.
Các kỹ thuật phổ biến sử dụng trong các cuộc tấn công:
URL Tampering: Kẻ tấn công sẽ chỉnh sửa tham số truy vấn trong URL để truy cập vào dữ liệu nhạy cảm của người dùng khác.
Form Manipulation: Kẻ tấn công chỉnh sửa các tham số ẩn trong form để truy cập trái phép vào dữ liệu.
Body Data Manipulation: Kẻ tấn công chặn bắt gói tin để can thiệp vào dữ liệu được gửi đi và thay đổi ID đối tượng.
Brute-force ID: Kẻ tấn công sẽ sử dụng các công cụ tự động để rà quét các IPs.
Header/Cookie Manipulation: Kẻ tấn công thay đổi các giá trị tham chiếu được truyền qua HTTP Headers (VD: X-User-ID) hoặc bên trong Cookie để chiếm phiên làm việc hoặc lấy dữ liệu từ đối tượng khác.
Thay đổi phương thức HTTP: Kẻ tấn công thử thay đổi phương thức request. Hệ thống có thể chặn IDOR đối với GET nhưng lại quên chặn đối với POST.
Tiêm tham số/mảng: Vượt qua bộ lọc xác thực bằng cách truyền nhiều tham số cùng tên hoặc thay đổi kiểu dữ liệu thành mảng để đánh lừa logic kiểm tra của ứng dụng.
Những loại chức năng hoặc dữ liệu nào trên trang web có thể bị ảnh hưởng khi lỗ hổng IDOR bị khai thác?
Truy cập vào trang chủ bài Lab: https://[LAB-ID].web-security-academy.net/. Để giải bài lab, chúng ta cần tìm mật khẩu tài khoản carlos, sau đó đăng nhập vào tài khoản.
Thử dùng chức năng Live chat, quan sát các gói request trong Burp Suite.
Thử click vào chức năng View transcript, quan sát hành vi trang web trên burp suite.
Quan sát gói tin, chúng ta có thể nhận thấy rằng sau khi click vào nút View transcript, trang web sẽ chuyển hướng 302 đến /download-transcript/2.txt
GET request đến /download-transcript/2.txt sẽ nhận được response chứa nội dung chat hiện tại. Chúng ta có thể nhận thấy rằng, sau mỗi lần nhất View transcript, trang web sẽ trả về file txt có tên tăng dần (2,3,4,…). Vậy cái chúng ta cần lấy là file 1.txt vì rất có thể mật khẩu carlos nằm trong đó.
Thử truy cập vào đường dẫn /download-transcript/1.txt xem sao.
Đọc nội dung chat, chúng ta có thể dễ dàng lấy được mật khẩu 468mvitb1ekls7prnu0c. Đó có thể là mật khẩu của Carlos. Chúng ta sẽ dùng thông tin carlos:468mvitb1ekls7prnu0c để đăng nhập.
Web Security Iaw301 -
Bài viết này là một phần của loạt bài.
