Hí anh em! Tôi saiury92 đây ! Phận làm dev mười hai bến nước , trong nhờ đục chịu. Code thì phải làm bảo deadline, đúng estimate, nhưng lại phải không có bug, sếp thì lúc nào cũng dí ! Qua ông sếp mới sang vỗ vai bảo “chú code tốt, bug thì cũng ít đấy nhưng security của dự án thì thế nào em ?” Hả security là cái quái gì ? Mình code đúng theo yêu cầu spec của khách hàng là được rồi mà ! Thế là tôi lại phải đi hỏi ChatGPT, Bard,… thì mới ớ người ra, vấn đề bảo mật nó còn quan trọng hơn bất kỳ cái gì khác ! Dự án có code ngon đến đâu dính vào lỗ hổng bảo mật là bọn hacker nó vào phá nát như tương !
Chính thế !! Hôm nay tôi đưa đến cho các đồng dâm 10 vấn đề của API security thường gặp để anh em có thể vỗ ngực trước sếp “security à ! Cái này em được học từ trong bụng mẹ !”
1. Broken object level authorization
Sở dĩ Broken object level authorization nằm top 1 là vì hacker không cần sử dụng phương pháp tấn công gì cao siêu, chỉ cần thay thế ID tài nguyên của họ bằng ID tài nguyên thuộc về người dùng khác. Ví dụ như, kẻ tấn công biết được API có dạng /api/shopID/financial_info, chúng thử nghiệm thay thế từng shopID, nếu API không phân quyền user với từng shop thì hacker có thể xem được thông tin của tất cả các shop. Vấn đề có thể trầm trọng hơn khi ID là tuyến tính có thể liệt kê ra được (ID: 1,2,3,..).
Cách phòng chống:
- Thực hiện kiểm tra ủy quyền chặt chẽ với từng API và nên xây dựng hệ thống phân quyền có cấp bậc với từng tài nguyên. Chỉ những user có quyền xem financial_info của shop1ID mới có quyền call API /api/shop1ID/financial_info.
- Không nên dựa vào ID phía client gửi, sử dụng ID được lưu trữ trong session. Thay vì sử dụng /api/shopID/financial_info, ta có thể sử dụng /api/financial_info lấy thông tin shop dựa vào current_user.
- Sử dụng random IDs để kẻ tấn công không thể đoán được (UUIDs – /api/cc20c3ec-1fcc-4912-a0bc-b361d1180b63/financial_info).
- Triển khai test case đầy đủ để ngăn ngừa lỗ hổng này.
2. Broken authentication
Broken object level authorization là lỗ hổng liên quan đến phân quyền, còn broken authentication là xác thực. Xác thực API được triển khai kém cho phép hacker giả định danh tính của người dùng khác hoặc truy cập tài nguyên mà không cần bất kỳ xác thực nào.
Nguyên nhân dẫn đến broken authentication:
- Những internal API không có authentication. Một số API nằm trong private network chúng ta mặc định đã an toàn mà bỏ qua việc xác thực.
- Có cơ chế xác thực nhưng cơ thể xác thực đơn giản, API key yếu, dễ đoán không rotate định kỳ.
- Mật khẩu yếu, plain text, hàm băm kém, mật khẩu dùng chung hoặc mật khẩu mặc định. Một số hệ thống tự động tạo password mặc định nhưng password dễ đoán mà không có chức năng reset password lần login đầu tiên.
- Authentication dễ bị brute force attacks. Brute force attacks là kiểu tấn công mà hacker sẽ cố gắng đoán mật khẩu hoặc các thông tin xác thực khác bằng cách thử tất cả các kết hợp ký tự có thể.
- Thông tin credentials and keys bị lộ trong URLs.
- Cơ chế xác thực yếu, JWT token chỉ decode mà không verify signature (chữ ký).
- Sử dụng token vĩnh viễn, không hết hạn.
Cách phòng chống:
- Kiểm tra tất cả các API đã xác thực chưa, nếu có thì các cách có thể xác thực.
- API cho password reset and one-time links để authenticate cần được bảo mật, có thể đính kèm với one-time verification code.
- Sử dụng những phương pháp tiêu chuẩn có sẵn để generate token (JWT), lưu trữ password và multi-factor authentication (MFA).
- Sử dụng rate-limiting cho việc authentication (quy định hạn mức request authenticate thất bại), thực hiện các chính sách lockout khi có nghi ngờ, kiểm tra password yếu của người dùng.
3. Broken Object Property Level Authorization
API endpoints có thể bị tấn công dựa vào data của chúng (request data, response data): response data tiết lộ nhiều thông tin hơn mục đích business (excessive information exposure), chấp nhận và xử lý nhiều request data hơn mức cần thiết (mass assignment).
Nhiều API trả về toàn bộ dữ liệu thuộc tính của object (user->toJson()), việc lọc dữ liệu cần thiết để hiển thị được hiện bên phía client. Kể tấn công có thể lấy các dữ liệu nhạy cảm, phân tích để biết được các fields của object của database để tấn công mass assignment.
Mass assignment ở đây là cách kẻ tấn công bổ sung thêm các fields nhạy cảm vào request payload gửi lên API. API không lọc dữ liệu đầu vào, permit data, bind toàn bộ params data sang object và lưu object đó vào database. Kẻ tấn công có thể chỉnh sửa thông tin nhạy cảm, thay đổi role người dùng,…
Cách phòng chống:
- Không trả về toàn bộ dữ liệu và dữ liệu phải được lọc ở server trước khi trả về cho client. Chỉ tiết lộ dữ liệu cần thiết để hiển thị phía client.
- Xác định các dữ liệu nhạy cảm và tránh tiết lộ các thông tin này: Personally Identifiable Information (PII – email, phone, passport, Social Security number), Payment Card Industry (PCI).
- Không tự động assign params data tới objects. Cần permit params, payload data, lọc và lấy dữ liệu cần thiết.
- Sử dụng readOnly với những thuộc tính có thể truy xuất qua API mà không bao giờ được sửa đổi.
Trên đây là top 3 lỗ hổng bảo mật hàng đầu ! Thui buồn ngủ rùi hẹn các đồng dâm ở part II nha !
Reference
2 comments
Mở bài chất lượng luôn =))
Zaproxy dolore alias impedit expedita quisquam.