OWASP CRS lộ lỗ hổng nguy hiểm cho phép vượt tường lửa web, tấn công XSS

[WhiteHat Team]

OWASP Core Rule Set (CRS) từ lâu được xem là bộ quy tắc phòng thủ cốt lõi cho hàng triệu hệ thống web trên toàn cầu, đóng vai trò như “lá chắn” bảo vệ ứng dụng khỏi các cuộc tấn công phổ biến như SQL Injection hay Cross-Site Scripting (XSS). Tuy nhiên, mới đây, lỗ hổng bảo mật ở mức CRITICAL đã bị phát hiện trong chính OWASP CRS, cho phép kẻ tấn công vượt qua cơ chế kiểm tra charset trong các yêu cầu multipart/form-data, từ đó đưa mã độc trực tiếp tới hệ thống phía sau tường lửa.
​

Lỗ hổng này không chỉ ảnh hưởng tới một phiên bản riêng lẻ, mà tồn tại trong toàn bộ các phiên bản CRS được hỗ trợ suốt nhiều năm qua, đặt ra rủi ro lớn cho các tổ chức đang tin tưởng tuyệt đối vào lớp bảo vệ WAF.

Lỗ hổng được định danh là CVE-2026-21876, với điểm CVSS 9,3 - CRITICAL, ảnh hưởng trực tiếp tới rule 922110 của OWASP CRS. Đây là rule dùng để phát hiện và ngăn chặn các cuộc tấn công liên quan tới charset nguy hiểm trong các yêu cầu multipart/form-data, một định dạng thường được sử dụng khi upload dữ liệu hoặc gửi form phức tạp.

Điều đáng chú ý là rule 922110 được bật mặc định ở Paranoia Level 1, tức là ngay cả những hệ thống cấu hình WAF ở mức bảo vệ cơ bản nhất cũng đều chịu ảnh hưởng. Đây không phải lỗi lập trình đơn giản mà là hệ quả từ cách thiết kế và cơ chế xử lý rule của ModSecurity - engine phổ biến đứng sau nhiều WAF hiện nay.​

Nguyên nhân kỹ thuật: Khi cơ chế xử lý rule trở thành điểm yếu​

Về mặt kỹ thuật, rule 922110 được thiết kế để kiểm tra tham số charset trong header Content-Type của từng phần (part) trong một yêu cầu multipart. Mục tiêu là chặn các charset nguy hiểm như UTF-7, UTF-16, UTF-32, vốn có thể bị lợi dụng để che giấu mã độc, đặc biệt là tấn công XSS.

Tuy nhiên, vấn đề nằm ở cách ModSecurity xử lý chained rules khi duyệt qua các collection variables. Khi engine lần lượt xử lý từng MULTIPART_PART_HEADERS, giá trị charset của mỗi phần sẽ được lưu vào biến tạm (TX:1). Nhưng biến này bị ghi đè ở mỗi vòng lặp, và đến khi rule chained phía sau được thực thi, chỉ còn lại giá trị của phần cuối cùng.

Nói cách khác, hệ thống chỉ kiểm tra charset của multipart part cuối, trong khi các phần trước đó hoàn toàn không được xác thực.​

Cơ chế khai thác: Vượt WAF chỉ bằng một yêu cầu multipart​

Kẻ tấn công có thể lợi dụng hành vi này bằng cách tạo một yêu cầu multipart với nhiều phần dữ liệu. Phần đầu tiên chứa payload độc hại được mã hóa bằng UTF-7 (một charset nguy hiểm cho phép biểu diễn thẻ HTML và JavaScript theo cách khó phát hiện). Phần cuối cùng lại sử dụng charset UTF-8 hợp lệ.

Do rule 922110 chỉ xác thực phần cuối, WAF sẽ cho phép toàn bộ request đi qua, trong khi payload XSS đã nằm sẵn ở phần đầu và được chuyển thẳng tới ứng dụng backend. Điều này khiến tường lửa ứng dụng web bị vô hiệu hóa hoàn toàn trong kịch bản tấn công này, dù không có bất kỳ cảnh báo nào được ghi nhận.​

Mức độ nguy hiểm và phạm vi ảnh hưởng​

Lỗ hổng được đánh giá CRITICAL không chỉ vì điểm kỹ thuật, mà còn bởi các yếu tố thực tế:​

• Không yêu cầu xác thực​
• Không cần tương tác người dùng​
• Payload dễ xây dựng, không đòi hỏi kỹ thuật cao​
• Ảnh hưởng tới tất cả các hệ thống sử dụng CRS từ phiên bản 3.0.0 đến 4.21.0​

Quan trọng hơn, lỗ hổng này phá vỡ ranh giới bảo mật giữa WAF và ứng dụng phía sau. Nhiều tổ chức tin rằng chỉ cần WAF là đủ an toàn, trong khi backend vẫn tồn tại các điểm yếu XSS chưa được vá.​

Rủi ro và hậu quả nếu bị khai thác​

• Nếu lỗ hổng này bị khai thác thành công, hậu quả có thể rất nghiêm trọng:​
• Kẻ tấn công chèn mã JavaScript độc hại vào ứng dụng web​
• Đánh cắp cookie phiên, token xác thực của người dùng​
• Chiếm quyền tài khoản, đặc biệt với các hệ thống quản trị​
• Phát tán mã độc hoặc chuyển hướng người dùng tới trang lừa đảo​
• Gây tổn hại uy tín và dữ liệu của tổ chức​

Với các hệ thống lớn như cổng dịch vụ công, ngân hàng, thương mại điện tử, đây là kịch bản rủi ro cao.​

Giải pháp khắc phục và khuyến nghị từ chuyên gia​

OWASP CRS đã phát hành bản vá chính thức vào ngày 6/1/2026:​

• Người dùng CRS 4.x cần nâng cấp lên CRS 4.22.0​
• Người dùng CRS 3.3.x cần nâng cấp lên CRS 3.3.8​

Bản vá khắc phục bằng cách xác thực toàn bộ các phần multipart, thay vì chỉ phần cuối. Cơ chế mới sử dụng bộ đếm tăng dần để lưu riêng từng charset, sau đó kiểm tra tất cả các giá trị thu thập được. Cách làm này tương thích với ModSecurity v2, v3 và cả Coraza WAF.

Trong trường hợp chưa thể nâng cấp ngay, không có biện pháp tạm thời an toàn ngoài việc vô hiệu hóa rule 922110, nhưng điều này đồng nghĩa với việc hệ thống sẽ mở cửa cho các tấn công dựa trên charset (một rủi ro không được khuyến khích).

Các chuyên gia an ninh mạng khuyến cáo:​

• Kiểm tra ngay phiên bản OWASP CRS đang sử dụng​
• Ưu tiên nâng cấp WAF trong các hệ thống quan trọng​
• Không phụ thuộc hoàn toàn vào WAF, cần kết hợp kiểm tra đầu vào ở backend​
• Theo dõi log WAF để phát hiện hành vi multipart bất thường​

Lỗ hổng CVE-2026-21876 là lời nhắc nhở rõ ràng rằng ngay cả những thành phần bảo mật cốt lõi, được tin dùng rộng rãi nhất, cũng có thể tồn tại điểm mù nghiêm trọng. Trong bối cảnh tấn công ngày càng tinh vi, việc cập nhật, rà soát và hiểu rõ cơ chế bảo vệ đang sử dụng là điều bắt buộc, không chỉ với chuyên gia bảo mật mà cả với đội ngũ vận hành hệ thống.

An ninh mạng không phải là trạng thái “đã xong” mà là một quá trình liên tục. Và trong quá trình đó, sự chậm trễ trong cập nhật đôi khi chính là lỗ hổng nguy hiểm nhất.​

WhiteHat​