Định nghĩa
Rate limiting là một điều khiển quản lý lưu lượng thực thi giới hạn trên về tần suất một khách hàng có thể thực hiện một hành động cụ thể trong một cửa sổ thời gian được chỉ định. Khi một khách hàng vượt quá ngưỡng, máy chủ phản hồi với lỗi — thường là HTTP 429 Too Many Requests — hoặc âm thầm loại bỏ các yêu cầu thừa. Cửa sổ thời gian đặt lại theo lịch trình cố định (bộ đếm “cửa sổ cố định”) hoặc trên cơ sở cuộn (bộ đếm “cửa sổ cuộn”), với các cửa sổ cuộn cung cấp việc thực thi mượt mà hơn ngăn chặn khai thác đột phá tại các ranh giới cửa sổ.
Rate limiting là một trong những điều khiển bảo mật web cổ xưa nhất và được triển khai phổ biến nhất. OWASP (Open Web Application Security Project) khuyến nghị nó như một biện pháp phòng thủ chính chống lại các cuộc tấn công vũ phu, nhồi nhét thông tin đăng nhập và lạm dụng biểu mẫu tự động. Cloudflare cung cấp rate limiting như một tính năng của sản phẩm WAF của mình, với các quy tắc có thể cấu hình theo đường dẫn URL, phương thức HTTP, địa chỉ IP, giá trị cookie và tiêu đề yêu cầu. AWS WAF, Azure Front Door và Google Cloud Armor cung cấp các khả năng tương đương.
Rate Limiting hoạt động như thế nào
Một bộ giới hạn tốc độ duy trì một bộ đếm cho mỗi định danh khách hàng duy nhất — phổ biến nhất là địa chỉ IP nguồn, nhưng đôi khi là một định danh tài khoản, một khóa API hoặc một cookie phiên. Khi một yêu cầu đến, máy chủ kiểm tra giá trị bộ đếm hiện tại cho định danh đó. Nếu bộ đếm dưới ngưỡng, yêu cầu được cho phép và bộ đếm tăng lên. Nếu bộ đếm ở ngưỡng hoặc trên ngưỡng, yêu cầu bị từ chối với phản hồi 429 hoặc được xử lý theo chính sách được cấu hình.
Lưu trữ bộ đếm thường được triển khai trong Redis hoặc Memcached để cho phép các tra cứu phân tán nhanh chóng qua nhiều phiên bản máy chủ — một yêu cầu cho các ứng dụng được mở rộng theo chiều ngang. Tài liệu Cloudflare mô tả việc thực thi rate limiting ở cấp mạng biên, nơi các quy tắc được áp dụng trước khi các yêu cầu đến máy chủ origin, phân phối việc giảm tải qua cơ sở hạ tầng toàn cầu của Cloudflare.
Các tham số rate limiting phổ biến trong ngữ cảnh cuộc thi bao gồm:
- Phiếu bầu trên mỗi IP trên mỗi cửa sổ thời gian: Cấu hình phổ biến nhất. Ví dụ: không quá 1 phiếu bầu trên mỗi địa chỉ IP trên mỗi cửa sổ 24 giờ.
- Phiếu bầu trên mỗi tài khoản trên mỗi cuộc thi: Được thực thi ở lớp ứng dụng bằng cách sử dụng định danh tài khoản của người dùng đã xác thực làm khóa.
- Đăng ký trên mỗi IP trên mỗi giờ: Được áp dụng tại điểm cuối tạo tài khoản để làm chậm việc tạo tài khoản do bot điều khiển.
- Cuộc gọi API trên mỗi mã thông báo trên mỗi phút: Có liên quan đến các nền tảng cuộc thi cung cấp một API bỏ phiếu công khai.
Rate limiting cũng có thể được áp dụng theo xác suất — ví dụ, áp dụng các giới hạn nghiêm ngặt hơn cho các yêu cầu đến với các tín hiệu hành vi hoặc dấu vân tay gợi ý tự động hóa, đồng thời áp dụng các giới hạn lỏng lẻo hơn cho các phiên có chỉ báo con người tin cậy cao.
Bạn gặp Rate Limiting ở đâu
Rate limiting là một điều khiển phổ biến hiện diện trong hầu như mọi nền tảng web. Các nhà điều hành cuộc thi gặp nó trực tiếp nhất tại ba điểm: điểm cuối gửi phiếu bầu, biểu mẫu đăng ký tài khoản và (nếu xác nhận email được yêu cầu) pipeline gửi email. Các tích hợp cuộc thi do API thúc đẩy gặp các giới hạn tốc độ trên các điểm cuối API của nền tảng.
Đối với người dùng cuối, rate limiting biểu hiện rõ ràng nhất là một lỗi HTTP 429 hoặc một thông báo cụ thể của nền tảng như “Bạn đã bỏ phiếu” hoặc “Vui lòng đợi trước khi bỏ phiếu lại”. Nhiều nền tảng triển khai rate limiting mềm — chấp nhận yêu cầu nhưng âm thầm loại bỏ bản sao — để tránh báo hiệu sự tồn tại của điều khiển cho những kẻ lạm dụng tiềm năng.
Tài liệu rate limiting WAF của Cloudflare lưu ý rằng các quy tắc rate limiting có thể được đặt để ghi nhật ký mà không chặn trong giai đoạn phân tích, sau đó chuyển sang chặn khi ngưỡng thích hợp được hiệu chuẩn. Cách tiếp cận hai giai đoạn này giúp các nhà điều hành cuộc thi tránh chặn các đợt tăng đột biến phiếu bầu hợp pháp một cách vô tình.
Ví dụ thực tế
Một cuộc thi giải thưởng food blogger cấu hình hệ thống bỏ phiếu của mình với giới hạn tốc độ 24 giờ trên mỗi IP. Trong tuần cuối cùng của cuộc thi, một người bỏ phiếu cố gắng gửi 50 phiếu bầu liên tiếp nhanh chóng từ cùng một địa chỉ IP dân cư. Phiếu đầu tiên được chấp nhận; 49 yêu cầu tiếp theo nhận được phản hồi 429. Trình duyệt của người bỏ phiếu hiển thị một thông báo giải thích giới hạn một lần mỗi ngày.
Một nền tảng cuộc thi SaaS lưu trữ hàng trăm cuộc thi đồng thời sử dụng rate limiting của Cloudflare ở biên mạng. Một bot nhắm mục tiêu một cuộc thi với 10.000 yêu cầu mỗi phút bị giới hạn tối đa 60 yêu cầu mỗi phút ở biên, với các yêu cầu thừa không bao giờ đến máy chủ origin. Nhật ký của máy chủ origin chỉ hiển thị lưu lượng bị giới hạn, và việc sử dụng CPU phía máy chủ vẫn không bị ảnh hưởng.
Một đánh giá bảo mật OWASP của một microsite cuộc thi tùy chỉnh của một startup xác định việc thiếu rate limiting trên điểm cuối gửi lại xác nhận email là một lỗ hổng — kẻ tấn công có thể làm ngập hộp thư đến của nạn nhân bằng cách kích hoạt hàng nghìn email xác nhận. Đánh giá khuyến nghị triển khai giới hạn tốc độ 3 yêu cầu gửi lại trên mỗi địa chỉ email trên mỗi giờ, phù hợp với hướng dẫn phòng chống vũ phu của OWASP.
Khái niệm liên quan
Phát hiện bất thường là một bổ sung tinh vi hơn cho rate limiting: nơi rate limiting thực thi các ngưỡng cứng, phát hiện bất thường xác định các sai lệch khỏi cơ sở hành vi đã học, bắt các chiến dịch gian lận chỉ ở dưới các giới hạn cố định. Đa dạng ASN trở nên có liên quan khi các giới hạn tốc độ được áp dụng trên mỗi IP và một kẻ xấu phân phối các yêu cầu qua nhiều địa chỉ IP để ở dưới các ngưỡng trên mỗi IP — phân tích cấp ASN phát hiện mẫu tổng hợp. reCAPTCHA v3 cung cấp một điểm rủi ro hành vi có thể được kết hợp với rate limiting để áp dụng các giới hạn nghiêm ngặt hơn một cách chọn lọc cho các phiên có điểm là tự động tiềm năng.
Hạn chế / Lưu ý
Rate limiting dựa trên IP ít hiệu quả hơn trong các môi trường có carrier-grade NAT, nơi một IP công cộng duy nhất có thể đại diện cho hàng trăm thuê bao di động hợp pháp. Một giới hạn tốc độ trên mỗi IP của 1 phiếu bầu trên mỗi 24 giờ sẽ ngăn cản hầu hết các thuê bao đó bỏ phiếu một cách không đúng. Đây là lý do tại sao rate limiting trên các nền tảng cuộc thi phải được phân lớp với khử trùng lặp dựa trên tài khoản hoặc cookie khi đối tượng di động đáng kể. Ngoài ra, các giới hạn tốc độ được đặt quá quyết liệt có thể làm giảm trải nghiệm cho những người bỏ phiếu hợp pháp đến từ các mạng được chia sẻ như khuôn viên trường đại học, văn phòng doanh nghiệp hoặc các điểm phát Wi-Fi công cộng lớn.
