Cloudflare sử dụng tác nhân AI để kiểm thử tải cho tường lửa ứng dụng web của chính mình

Các kỹ sư của Cloudflare gần đây đã đưa Tường lửa Ứng dụng Web (WAF) của chính họ vào một bài kiểm tra tải khắt khe bằng cách sử dụng các mô hình ngôn ngữ lớn (LLM) tiên tiến. Nghiên cứu được công bố vào ngày 29 tháng 9 năm 2026, chi tiết hóa cách một hệ thống tự động đóng vai trò là hacker đối thủ, lặp lại hàng nghìn biến thể payload để tìm ra những điểm mù trong các biện pháp phòng thủ thời gian thực. Thí nghiệm này đã phơi bày những điểm yếu cụ thể trong việc xử lý các nỗ lực giả mạo yêu cầu phía máy chủ (SSRF) bị che giấu và chèn lệnh, dẫn đến các bản cập nhật ngay lập tức cho các bộ quy tắc quản lý (managed rulesets) của Cloudflare.

Điều gì đã xảy ra

Nhóm bảo mật đã xây dựng một khung kiểm thử tùy chỉnh dựa trên Python để đánh giá xem các mô hình AI hiện đại có thể vượt qua các lớp bảo vệ WAF hiệu quả hơn so với các công cụ phân tích tĩnh hoặc động truyền thống hay không. Khác với kiểm thử xâm nhập tiêu chuẩn, hệ thống này sử dụng LLM để biến đổi động các vector tấn công dựa trên phản hồi HTTP trực tiếp. Công cụ kiểm thử không có quyền truy cập vào mã nguồn hoặc các quy tắc WAF nội bộ, chỉ dựa vào dữ liệu phản hồi được chọn lọc để hướng dẫn bước đi tiếp theo. Cách tiếp cận hộp đen này mô phỏng cách mà một kẻ tấn công bên ngoài có thể thăm dò một ứng dụng được bảo vệ mà không có kiến thức trước về cơ sở hạ tầng của nó.

Bài kiểm thử được chạy trên môi trường staging của khách hàng được ủy quyền, cấu hình với các thiết lập nghiêm ngặt nhất của Cloudflare, bao gồm chặn WAF Attack Score ở mức 30 trở xuống và OWASP Core Ruleset ở Paranoia Level 3. Trong suốt quá trình thí nghiệm, hệ thống đã thực hiện 1.107 lần thử biến đổi trên 45 kịch bản bao phủ sáu danh mục tấn công chính: cross-site scripting, SQL injection, command injection, server-side request forgery, path traversal và các khai thác Log4j. Mặc dù phần lớn các cuộc tấn công đều bị chặn, quy trình này đã xác định được 49 phát hiện cụ thể cần sự xem xét của con người và các biện pháp giảm thiểu sau đó.

Hầu hết các trường hợp vượt qua thành công thuộc vào hai danh mục: chèn lệnh và giả mạo yêu cầu phía máy chủ (SSRF). Ví dụ, trong một kịch bản SSRF, mô hình phát hiện ra rằng việc biểu diễn địa chỉ IP metadata đám mây với một dấu chấm cuối cùng cho phép nó tránh bị phát hiện, trong khi các biểu diễn thập phân hoặc bát phân tiêu chuẩn thì không. Những phát hiện này không phải là các khai thác được xác nhận, mà là các manh mối chỉ ra rằng logic chuẩn hóa của WAF có thể xử lý các trường hợp biên giới khác nhau. Nhóm đã sử dụng những hiểu biết này để tinh chỉnh các engine phát hiện, dẫn đến các quy tắc mới cho các host bị che giấu và các giao thức bị hạn chế.

Cơ chế hoạt động

Hệ thống kiểm thử hoạt động dựa trên một vòng lặp thích ứng được điều khiển bởi hai lần gọi LLM riêng biệt cho mỗi lần lặp. Lần gọi đầu tiên, giai đoạn đề xuất, nhận ngữ cảnh yêu cầu ban đầu và lịch sử kết quả trước đó để gợi ý một biến thể mới. Nó có thể thay đổi encoding, di chuyển payload sang một phần khác của yêu cầu HTTP, hoặc thay đổi định dạng đích. Lần gọi thứ hai, giai đoạn xem xét, phân tích trạng thái phản hồi, headers và body để xác định xem nỗ lực đó thành công hay bị chặn. Vòng lặp phản hồi này cho phép mô hình học được những biến đổi nào hiệu quả mà không bao giờ nhìn thấy các biểu thức quy tắc WAF cơ bản hoặc điểm số tấn công.

Quan trọng hơn, mã nguồn duy trì sự kiểm soát chặt chẽ đối với môi trường thực thi. LLM không gửi yêu cầu trực tiếp; thay vào đó, nó tạo ra các gợi ý mà khung kiểm thử Python sẽ xác thực và thực thi. Trước mỗi yêu cầu, hệ thống kiểm tra hostname đích so với allowlist, vô hiệu hóa redirect và áp đặt giới hạn cứng về số lần thử. Sau mỗi phản hồi, hệ thống ghi lại bằng chứng có cấu trúc, coi bất kỳ văn bản trả về nào là input không đáng tin cậy. Thiết kế này đảm bảo rằng quy trình kiểm thử vẫn an toàn và có thể tái lập, ngăn ngừa AI gây ra thiệt hại không mong muốn hoặc rò rỉ dữ liệu nhạy cảm trong quá trình đánh giá.

Chi tiết chính

• Bài kiểm thử đã tạo ra 1.107 lần thử biến đổi, với 558 lần bị WAF chặn rõ ràng trước khi đến được ứng dụng.
• Việc phân loại bởi con người đã giảm đầu ra thô xuống còn 49 phát hiện hợp lệ, 48 trong số đó liên quan đến chèn lệnh hoặc SSRF.
• Cấu hình WAF bao gồm chặn WAF Attack Score ở mức 30 trở xuống và OWASP Core Ruleset ở Paranoia Level 3.
• Các phát hiện mới cho host SSRF bị che giấu và giao thức bị hạn chế đã được thêm vào Managed Ruleset sau bài kiểm thử.
• Hệ thống sử dụng hai lần gọi LLM riêng biệt cho mỗi lần lặp: một để đề xuất biến đổi và một để xem xét phản hồi.
• Các yêu cầu vượt qua WAF được coi là manh mối để điều tra, không phải là khai thác được xác nhận, đòi hỏi sự xác thực thêm.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và lãnh đạo bảo mật, nghiên cứu này làm nổi bật những hạn chế của các biện pháp phòng thủ tĩnh dựa trên quy tắc chống lại các đối thủ thích ứng. Các bài kiểm thử xâm nhập truyền thống thường tuân theo các script định nghĩa trước, bỏ lỡ các kỹ thuật mã hóa mới lạ hoặc lỗi logic mà AI có thể khám phá thông qua lặp lại. Bằng cách chứng minh rằng LLM có thể tìm ra các lỗ hổng trong cả những WAF được cấu hình cao, Cloudflare nhấn mạnh nhu cầu về kiểm thử bảo mật tự động, liên tục, phát triển song hành với bối cảnh mối đe dọa. Nó gợi ý rằng việc chỉ dựa vào phát hiện dựa trên chữ ký (signature-based detection) là không đủ khi kẻ tấn công có thể sử dụng AI để tạo ra vô số biến thể của các khai thác đã biết.

Các phát hiện cũng củng cố tầm quan trọng của phòng thủ nhiều lớp (defense in depth). Ngay cả khi WAF không chặn được một yêu cầu biến đổi cụ thể, bản thân ứng dụng vẫn phải giữ an toàn. Trong ví dụ SSRF, việc vượt qua không dẫn đến rò rỉ dữ liệu vì lớp ứng dụng có khả năng đã có các biện pháp bảo vệ riêng hoặc yêu cầu bị sai định dạng theo cách ngăn cản khai thác thực tế. Điều này nhắc nhở các nhà phát triển rằng việc vá lỗi phần mềm và duy trì các dependency cập nhật là những bổ sung quan trọng cho các biện pháp kiểm soát bảo mật cấp mạng. WAF là một tấm khiên, không phải là phương thuốc chữa bách bệnh, và hiệu quả của nó phụ thuộc vào khả năng phục hồi của toàn bộ stack.

Bạn có thể làm gì

• Bật tất cả các managed rulesets có sẵn và đặt ngưỡng WAF Attack Score ở mức khuyến nghị phù hợp với hồ sơ rủi ro của bạn.
• Chạy các bài kiểm thử bảo mật ứng dụng hiện có trên môi trường staging được bảo vệ bởi cùng cấu hình WAF như production.
• Triển khai các biện pháp kiểm soát bảo mật tích cực xác định hình dạng yêu cầu dự kiến, giảm bề mặt tấn công cho các biến thể chưa biết.
• Xem xét các sự kiện bảo mật ở chế độ chỉ ghi log (log-only mode) trước khi áp dụng các quy tắc mới để xác định false positive và mẫu lưu lượng hợp lệ.
• Giữ cho các dependency và framework ứng dụng luôn được cập nhật để giảm thiểu các lỗ hổng có thể bị lộ nếu các lớp WAF thất bại.
• Cân nhắc sử dụng các công cụ kiểm thử do AI điều khiển để bổ sung cho các bài kiểm thử xâm nhập thủ công, tập trung vào biến đổi payload thích ứng.