28 tháng 10, 2025 ~24 phút đọc
Mục lục
Lỗ hổng CVE-2025-55315 là gì?
Vào ngày 14 tháng 10 năm 2025, trong ngày “patch Tuesday” tiêu chuẩn của Microsoft, công ty đã phát hành phiên bản mới cho tất cả các phiên bản .NET được hỗ trợ và công bố một khuyến cáo bảo mật: Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability.
Lỗ hổng này được Microsoft chấm điểm CVSS là 9.9/10 – mức cao nhất từ trước đến nay. Đúng là đáng để hoảng sợ, phải không?
Như Barry Dorrans (blowdart), người đứng đầu bộ phận bảo mật .NET, giải thích:
“Lỗi này cho phép HTTP Request Smuggling, và riêng với ASP.NET Core thì không đáng lo ngại đến vậy, nhưng đó không phải cách chúng tôi đánh giá… Chúng tôi chấm điểm dựa trên việc lỗi có thể ảnh hưởng thế nào đến các ứng dụng được xây dựng trên ASP.NET.
Request Smuggling cho phép kẻ tấn công ẩn một yêu cầu bên trong một yêu cầu khác, và yêu cầu bị ẩn đó có thể làm gì phụ thuộc rất nhiều vào ứng dụng cụ thể.”
HTTP Request Smuggling hoạt động như thế nào?
HTTP Request Smuggling là một kỹ thuật khai thác bảo mật đã được biết đến từ lâu (theo Wikipedia, nó được ghi nhận lần đầu vào năm 2005). Vấn đề cơ bản xảy ra khi bạn có hai server khác nhau xử lý một yêu cầu HTTP (ví dụ: một server và một proxy server), và hai server đó khác nhau về cách xử lý các yêu cầu HTTP “không hợp lệ”.
Tóm tắt quá trình khai thác:
- Proxy server nhận được yêu cầu HTTP mơ hồ
- Proxy server chuyển tiếp yêu cầu (không chỉnh sửa) đến server đích
- Server đích hiểu yêu cầu mơ hồ đó là hai yêu cầu HTTP được gửi tuần tự đến server, và xử lý chúng riêng biệt
Kẻ tấn công có thể khai thác Request Smuggling như thế nào?
Vấn đề với Request Smuggling thực sự nằm ở sự không khớp giữa proxy và server đích. Dựa vào sự không khớp này và tùy thuộc vào hành vi và kỳ vọng của ứng dụng đích, kẻ tấn công có thể sử dụng Request Smuggling để:
- Phản chiếu dữ liệu độc hại đến người dùng khác trên các trang web dễ bị cross-site scripting
- Làm nhiễm độc cache với dữ liệu xấu
- Lấy cắp thông tin xác thực hoặc dữ liệu khác từ các yêu cầu của client
- Gọi các endpoint không nên được truy cập công khai (vì proxy sẽ chặn truy cập bên ngoài)
- Thay thế/ghi đè các kiểm soát xác thực được xử lý bởi proxy
- Chuyển hướng người dùng đến các trang web độc hại trên các trang web dễ bị open-redirect attacks
- Và nhiều hơn nữa…
Request Smuggling chỉ áp dụng nếu tôi có proxy?
Không hẳn vậy. Đặc điểm chính của lỗ hổng này là có khả năng gây nhầm lẫn giữa hai “hệ thống”, dù chúng có phải là “server” đầy đủ hay không. Điều này rõ ràng áp dụng cho proxy servers, nhưng cũng có thể áp dụng cho ứng dụng của bạn nếu bạn đang làm bất cứ điều gì liên quan đến việc đọc/thao tác/chuyển tiếp luồng yêu cầu, hoặc nơi có khả năng nhầm lẫn bên trong cùng một ứng dụng.
Request Smuggling trong CVE-2025-55315 hoạt động như thế nào?
Lỗ hổng Request Smuggling trong CVE-2025-55315 dựa vào một biến thể được báo cáo lần đầu vào tháng 6 năm 2025. Biến thể này dựa vào Transfer-Encoding và tính năng Chunk Extensions.
Transfer-Encoding: chunked và chunk extensions
Khi bạn gửi một yêu cầu, đôi khi bạn không biết trước yêu cầu bạn đang gửi lớn đến đâu. Transfer-Encoding: chunked cho phép gửi dữ liệu yêu cầu trong nhiều “chunk”.
Chunk extensions là một phần của giao thức HTTP 1.1 cho phép thêm các cặp key-value metadata vào các chunk riêng lẻ. Chúng không phải là phần dữ liệu được xem bởi trình xử lý yêu cầu; chúng chỉ là metadata về chunk riêng lẻ.
Chunk extensions không hợp lệ với các line ending không chính xác
Vấn đề là cách triển khai bỏ qua chúng… Sự mơ hồ trong việc các server tìm kiếm \r\n. Điều gì xảy ra nếu chúng thấy một \r đơn lẻ, hoặc một \n đơn lẻ? Có phải chúng coi đó giống như \r\n không?
Sự mơ hồ đó là trọng tâm của lỗ hổng Request Smuggling CVE-2025-55315. Sự khác biệt trong cách xử lý của các triển khai proxy và server đối với \r hoặc \n riêng lẻ trong chunk header cho phép các cuộc tấn công Request Smuggling sử dụng sự mơ hồ này.
Khai thác chunk extensions không hợp lệ cho Request Smuggling
Cũng như các ví dụ khác về Request Smuggling, cách tiếp cận chunk extensions dựa vào sự khác biệt trong cách proxy phân tích cú pháp yêu cầu so với server tiếp theo. Sự khác biệt này có nghĩa là proxy thấy một yêu cầu, trong khi server đích thấy hai yêu cầu, và cho phép tất cả các cuộc tấn công giống nhau được thảo luận trước đó.
Lỗ hổng đã được sửa như thế nào?
Như với hầu hết các bản sửa lỗi cho request-smuggling, giải pháp là ngừng khoan dung và/hoặc mơ hồ về cách xử lý các line ending riêng lẻ trong chunk headers.
Trong ASP.NET Core, PR sửa lỗi này thực hiện bằng cách kiểm tra rõ ràng cho bất kỳ line ending nào, thay vì chỉ tìm kiếm \r. Nếu nó tìm thấy một line ending và nó không chính xác là \r\n, thì Kestrel hiện nay sẽ ném ra ngoại lệ KestrelBadHttpRequestException và trả về phản hồi 400.
Bạn nên làm gì?
Tin tốt ở đây là đã có bản sửa lỗi cho ASP.NET Core. Quan trọng là cập nhật lên phiên bản mới nhất được hỗ trợ của ASP.NET Core càng sớm càng tốt.
| Phiên bản | Các phiên bản dễ bị tổn thương | Phiên bản đã vá thấp nhất |
|---|---|---|
| .NET 10 | 10.0.0-rc1 | 10.0.0-rc2 |
| .NET 9 | 9.0.0 – 9.0.9 | 9.0.10 |
| .NET 8 | 8.0.0 – 8.0.20 | 8.0.21 |
Làm thế nào để biết bạn có bị ảnh hưởng không?
Cách “đơn giản nhất” để biết bạn có bị ảnh hưởng không là kiểm tra phiên bản .NET bạn đang sử dụng để chạy ứng dụng của mình, sử dụng dotnet --info và xác minh rằng bạn đang sử dụng một trong các phiên bản đã vá. Nếu có, bạn an toàn.
Điều đáng chú ý là đây là lỗ hổng trong HTTP/1.0 và HTTP/1.1 chỉ; nó không phải là lỗ hổng trong HTTP/2 hoặc HTTP/3. HTTP/2 và HTTP/3 không hỗ trợ chunked transfer encoding. Vì vậy, một cách khác để bảo vệ các ứng dụng mà bạn không thể nâng cấp có thể là buộc client chỉ có thể sử dụng HTTP/2 hoặc HTTP/3.
Tóm tắt
Trong bài viết này, tôi đã thảo luận về lỗ hổng ASP.NET Core gần đây: CVE-2025-55315. Khuyến cáo này cảnh báo về lỗ hổng Request Smuggling ảnh hưởng đến cơ bản tất cả các phiên bản của ASP.NET Core.
Tôi đã mô tả cách Request Smuggling hoạt động nói chung, sử dụng một ví dụ đơn giản để cho thấy sự mơ hồ trong cách phân tích cú pháp HTTP có thể dẫn đến proxy HTTP và server HTTP xử lý cùng một yêu cầu HTTP theo những cách khác nhau như thế nào.
Cuối cùng, tôi đã trình bày các bước giảm thiểu bạn nên thực hiện: vá ứng dụng của bạn. Nếu bạn đang chạy trong Azure App Services, thì bạn ổn, nhưng nếu không, bạn cần kiểm tra với nhà cung cấp proxy của mình để xác định xem bạn có dễ bị tổn thương hay không.
