Hí anh em! Tôi saiury92 đây ! Sau Part I, anh em thấy như thế nào? Có thấy nhột trong lòng sau khi nghĩ về những dự án trước đây đã release cho khách hàng mà vẫn tồn đọng các lỗ hổng bảo mật không ? Trong bài viết ngày hôm nay anh em còn thấy nhột hơn nữa vì 3 lỗ hổng tiếp theo đây, anh em hay mắc phải và thường tặc lưỡi bỏ qua khi code.
4. Unlimited Resource Consumption
API không được bảo vệ, dễ bị tổn thương trước số lượng request hoặc payload sizes quá lớn. Những kẻ tấn công có thể sử dụng điều này gây Denial of Service (DoS) cho hệ thống, hoặc brute force attacks để cố gắng authentication.
Lỗ hổng Unlimited Resource Consumption xảy ra khi API không có cơ chế hạn chế số lượng request tới server. Ví dụ chắc năng login bằng số điện thoại và mã OTP được gửi về số điện thoại, sau đó quá trình xác thực được thực hiện thông qua API POST /api/users/otp_verify. Kẻ tấn công sẽ dùng brute force attacks để tấn công API, random OTP từ 0000 -> 9999 để kiểm thử tìm ra OTP chính xác. Ngoài ra kẻ tấn công có thể upload file với kích thước quá lớn hoặc queries phức tạp khiến API gặp phải tình trạng tắc nghẽn và drop requests.
Cách phòng chống:
- Áp dụng chính sách rate-limiting cho tất cả API endpoints. Đặt biệt với những endpoints liên quan đến authentication là mục tiêu hàng đầu của những kẻ tấn công.
- Giới hạn số lượng requests có thể được thực hiện từ một địa chỉ IP hoặc người dùng trong một khoảng thời gian nhất định.
- Sử dụng keys, fingerprints, recaptcha, .. để giới hạn tốc độ requests.
- Giới hạn payload size và độ phức tạp của query.
- Giới hạn số lượng dữ liệu mà một truy vấn có thể truy xuất bằng cách áp dụng các giới hạn về pagination size, or page counts.
- Tận dụng các biện pháp bảo vệ DDoS từ cloud provider (AWS WAF, API Gateway, …).
5. Broken function level authorization
Ở Part I, chúng ta có broken object level authorization là lỗ hổng liên quan đến phân quyền truy cập đến các đối tượng, user1 có thể truy xuất dữ liệu của user2 thông qua thay đổi ID. Còn lỗ hổng broken function level authorization liên quan đến phân quyền các chức năng của hệ thống. Kẻ tấn công phán đoán các API ẩn với những đặc quyền cao hơn và thực thi chúng. Ví dụ kẻ tấn công có thể truy cập đến API /api/users/my_financial_info, bọn chúng phán đoán và thử thay đổi users -> admin truy cập vào API /api/admin/all_info, sự phân quyền yếu kém có thể dẫn đến việc lộ hết các thông tin nhạy cảm của tất cả users.
Cách phòng chống:
- Chia các API endpoints thành các function scope, phần quyền chặt chẽ theo từng scope.
- Kiểm soát truy cập các function trên server không bao giờ chỉ xử lý phân quyền ở phía client.
- Mặc định để deny all access các function. Chỉ cấp quyền với đối tượng cụ thể.
6. Unrestricted Access to Sensitive Business Flows
Khi các API thực hiện một business flow (quy trình đặt vé, mua sản phẩm, ..). Kẻ tấn công nắm được các business này, lợi dụng các API bằng các phương pháp tự động để đạt được mục đích xấu, chẳng hạn như lấy cắp dữ liệu hoặc thao túng dữ liệu thị trường hoặc giá cả.
Một business flow thường gặp và kịch bản tấn công:
- Purchasing a product flow – Kẻ tấn công sử dụng tính năng tự động để mua tất cả hàng tồn kho của một mặt hàng có nhu cầu cao cùng một lúc và bán lại với giá cao hơn.
- Creating a comment/post flow – Kẻ tấn công lợi dụng tính năng bình luận hoặc post bài viết để tự động spam hệ thống.
- Making a reservation – Kẻ tấn công có thể đặt tất cả các chỗ , ngăn chặn người dùng khác sử dụng hệ thống.
Cách phòng chống:
- Cần nắm vững các business flow, hiểu các business flow có thể dễ bị lạm dụng và thêm các lớp bảo vệ bổ sung cho các quy trình này, authentication là required.
- Áp dụng rate-limiting để hạn chế số lượng và tốc độ truy cập.
- Monitor số lượng truy cập API để phát hiện nguồn truy cập đáng ngờ.
- Identify non-human: Xác định xem đó có phải người dùng thao tác không chẳng hạn như kiểm tra giao dịch nhanh bất thường, thiết lập Captcha, human detection,..
Trong ba lỗ hổng trên, ý kiến cá nhân mình đánh giá Unrestricted Access to Sensitive Business Flows là anh em xác suất dính phải cao nhất, còn các anh em khác thấy như thế nào? Tự hỏi admin blog mình có cơ chế nào tránh việc comment spam không ta ?…….
Reference
