Phần 9 : API Sheild
Tại sao phải cần API Sheild ?
Nhiều công ty có hàng ngàn API, bao gồm các API mà họ không biết đến ⇒ giải pháp API Discovery
API hộ trợ lượng lớn người dùng ⇒ có thể bị tấn công nhồi nhét thông tin xác thực (credential-stuffing) và bị quét tự động bởi các công cụ độc hại. ⇒ giải pháp API Volumetric Abuse Detection
Với nhiều End-point API vậy rất khó để phát hiện tấn công brute-force ⇒ giải pháp API Volumetric Abuse Detection
Các cuộc tấn công tinh vi ẩn mình trong các lưu lượng hợp pháp vì đội ngũ phát triển ko thể giám sát chặt chẽ và ko hiểu được mô hình API để quản lý
Giới thiệu API Sheild
Cloudflare API Sheild được xây dựng dựa trên nhiều module và tính năng tích hợp với nhau để bảo vệ toàn diện cho API. Các module chính và cách chúng hỗ trợ bảo vệ API Sheild.
API Discovery
Sử dụng Machine Learning kết hợp với Session Identifier để phân tích lưu lượng API đang được sử dụng trong hệ thống. Có thể discover các API ẩn đang được sử dụng mà chưa được ghi nhận.
Tự động chuẩn hóa các API endpoint thay vì liệt kê tất cả ra rất khó để quản lý.
api.example.com/profile/238vàapi.example.com/profile/392→ Chuẩn hóa thànhapi.example.com/profile/{number}.
Sử dụng giao diện Inbox View : Các API nào mới được phát hiện sẽ được người dùng xem xét và đưa ra hành động save ( đưa qua dashboard Endpoint Management để theo dõi hiệu suất và áp dụng biện pháp bảo mật ) hoặc ignore ( không cần thiết theo dõi)
Endpoint Management
theo dõi và đánh giá độ trễ , tổng số request tới API endpoint. hiện thị bảng dashboard tổng quan để quan sát dễ dàng phân tích
Bộ đếm dựa theo session Identifier mà không theo IP , vì IP không thể đánh giá từng phiên người dùng có thể nhiều người dùng chung 1 IP public. Dựa theo session mà Cloudflare sẽ tự đề xuất overall rare litmit và các mốc p99 , p90 , p50 thể hiện tống số request trong 10p cho một session người dùng.
Sequence Analytics
Sequence Analytics theo dõi luồng thứ tự các request API theo từng session, giúp bạn hiểu cách người dùng tương tác với API và phát hiện hành vi bất thường hoặc tấn công sai chuỗi.
Cần cấu hình endpoint quản lý, chỉ số session xác định user, và hiểu rõ các giới hạn (10 request và 10 phút, v.v.). Phù hợp cho API tài chính giao dịch
CƠ CHẾ HOẠT ĐỘNG
🔹 1. Mỗi rule gồm 2 điểm:
Starting Endpoint: Endpoint cần được gọi trước.
Final Endpoint: Endpoint cần bảo vệ, chỉ cho phép gọi nếu đã qua endpoint trước.
⚠️ Rule chỉ hợp lệ nếu 2 endpoint nằm trong 10 request gần nhất, và xảy ra trong vòng 10 phút.
Mutual TLS (mTLS)
Mutual TLS (mTLS) là hình thức xác thực hai chiều (bidirectional) giữa client và server sử dụng chứng chỉ số (TLS certificates).
TLS thông thường (1 chiều): Chỉ server trình chứng chỉ để client tin tưởng.
mTLS (2 chiều): Cả server và client đều trình chứng chỉ để xác thực lẫn nhau.
phù hợp
Thiết bị IoT không có trình duyệt để đăng nhập (dùng mTLS thay vì SSO)
API nội bộ giữa microservices
Kết nối giữa client → Cloudflare → origin
Schema Validation
Cloudflare sẽ đối chiếu request đến với nội dung định nghĩa trong OpenAPI v3 Schema.
các yếu tố được kiểm tra
Method
Có khớp với schema
Path
Có tồn tại & đúng định dạng
Query
Có đúng key & đúng kiểu
Body
JSON đúng cấu trúc, kiểu, định dạng
Format
email, uuid, date, ip, v.v.
Charset
(nếu có) phải là utf-8
Labels
Cloudflare sẽ tự động gắn nhãn giúp tổ chức đánh giá và phát hiện lỗ hỏng trên từng API Shield. Ngoài ra bạn cũng có thể tự tạo nhãn để nhóm từng API Endpoint để quản lý.
Giải pháp Cloudflare cho các vấn đề bảo mật API (dựa trên OWASP API Security Top 10)
Broken Object Level Authorization (BOLA)
🛑 Tấn công: Truy cập dữ liệu của người khác - BOLA Enumeration Attack
Tình huống: Một hệ thống API quản lý tài khoản người dùng có endpoint:
Người dùng A đăng nhập và có
user_id=1234.Hacker thay đổi URL để truy cập dữ liệu người dùng khác:
Nếu API không kiểm tra quyền truy cập, hacker sẽ xem được thông tin cá nhân của người khác.
Giải pháp của Cloudflare : Labels
cf-risk-bola-enumeration: Khi endpoint bị truy cập thành công với số lượng element khác biệt bất thường giữa các session (ví dụ: nhiều userId bị quét bởi cùng một client).
🛑 Tấn công: Đầu đọc tham số - Parameter pollution attack
Tình huống:
tham số orderId xuất hiện cả ở URL path (/12345) và ở query string (?orderId=99999)
Lập trình viên viết code mới theo chuẩn, chỉ xử lý giá trị trên URL path.
Nhưng phần kiểm tra quyền (authorization) vẫn cũ, chỉ kiểm tra
orderIdlấy từ query string.Attacker là chủ order 99999, nhưng muốn cập nhật trạng thái của order 12345 (không thuộc về mình).
Attacker gửi request như trên.
Code kiểm tra quyền xác định: "orderId=99999" → hợp lệ với attacker.
Code xử lý cập nhật thực tế lại lấy path là user 12345 để update vào database.
Giải pháp của Cloudflare : Labels để detect kết hợp Custom Rule để block
cf-risk-bola-pollution: Khi endpoint trả về thành công mặc dù các tham số xuất hiện ở nhiều vị trí không đúng chuẩn schema của API (vd: vừa path, vừa query).Tạo custom rule với path không đúng biểu thức Regex thì chặn
🛑 Dữ liệu nhảy cảm
Tình huống:
Một số API sẽ trả về dữ liệu nhảy cảm ví dụ credit card,
Giải pháp của Cloudflare: Labels
cf-risk-sensitive: được áp dụng nếu khách hàng đã đăng ký bộ quy tắc phát hiện dữ liệu nhạy cảm và WAF phát hiện có dữ liệu nhạy cảm được trả về trên một endpoint
Last updated