Hiểu rõ lỗ hổng .NET nghiêm trọng nhất: request smuggling và CVE-2025-55315

Lỗ hổng CVE-2025-55315 là gì?

Vào ngày 14 tháng 10 năm 2025, Microsoft đã 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 cảnh báo bảo mật: Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability.

Tóm tắt từ thông báo cho biết: “Sự diễn giải không nhất quán của các yêu cầu HTTP (‘http request/response smuggling’) trong ASP.NET Core cho phép kẻ tấn công được ủy quyền vượt qua một tính năng bảo mật qua mạng.”

Lỗ hổng này được đánh giá CVSS 9.9/10 – mức cao nhất từ trước đến nay của Microsoft. Barry Dorrans (blowdart), trưởng bộ phận bảo mật .NET, giải thích lý do đằng sau điểm số này:

  • Request smuggling cho phép kẻ tấn công ẩn một yêu cầu bổ sung bên trong một yêu cầu khác
  • Yêu cầu bị đánh cắp có thể khiến mã ứng dụng của bạn thực hiện các hành động như: đăng nhập với tư cách người dùng khác, thực hiện yêu cầu nội bộ, bỏ qua kiểm tra CSRF, thực hiện tấn công injection

Request smuggling hoạt động như thế nào?

HTTP request smuggling là một lỗ hổng bảo mật đã được biết đến từ lâu (tài liệu đầu tiên năm 2005). Vấn đề cơ bản phát sinh khi có hai máy chủ khác nhau xử lý một yêu cầu HTTP (ví dụ: máy chủ và máy chủ proxy), và hai máy chủ này khác nhau về cách xử lý các yêu cầu HTTP “không hợp lệ”.

Kẻ tấn công tạo ra một yêu cầu HTTP không hợp lệ (hoặc đôi khi chỉ là yêu cầu mơ hồ) trông giống như hai yêu cầu HTTP được dán lại với nhau:


POST /some_script.jsp HTTP/1.0<br>
Connection: Keep-Alive<br>
Content-Type: application/x-www-form-urlencoded<br>
Content-Length: 9<br>
Content-Length: 204<br><br>
this=thatPOST /vuln_page.jsp HTTP/1.0<br>
Content-Type: application/x-www-form-urlencoded<br>
Content-Length: 95<br><br>
param1=value1&data=<script>alert("stealing%20your%20data:"%2bdocument.cookie)</script>&foobar

Đặc điểm quan trọng của yêu cầu này là có hai tiêu đề Content-Length với các giá trị khác nhau: 9 hoặc 204. Sự khác biệt giữa việc máy chủ proxy HTTP và máy chủ HTTP tôn trọng tiêu đề nào trong số hai tiêu đề đầu tiên này là nguyên nhân gây ra lỗ hổng.

Quá trình khai thác:

  • Máy chủ proxy nhận yêu cầu, ghi nhận các tiêu đề Content-Length trùng lặp và chấp nhận tiêu đề thứ hai, độ dài 204
  • Máy chủ proxy chuyển tiếp yêu cầu tới máy chủ đích
  • Máy chủ đích cũng ghi nhận tiêu đề Content-Length trùng lặp nhưng nó lấy tiêu đề đầu tiên, với độ dài 9
  • Máy chủ đọc 9 byte của phần thân (tức là this=that) và coi đó là toàn bộ yêu cầu

Máy chủ proxy thấy một yêu cầu, trong khi máy chủ đích thấy hai – yêu cầu thứ hai đã được “buôn lậu” qua proxy đến máy chủ.

Kẻ tấn công khai thác request smuggling như thế nào?

Kẻ tấn công có thể sử dụng request smuggling để:

  • Phản chiếu dữ liệu độc hại cho người dùng khác trên các trang web dễ bị tấn công cross-site scripting
  • Làm nhiễm độc bộ nhớ đệm bằng dữ liệu xấu
  • Đánh cắp thông tin xác thực hoặc dữ liệu khác từ yêu cầu của client
  • Gọi các endpoint không được công khai truy cập
  • 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

Một ví dụ về cuộc tấn công này:


POST /example HTTP/1.1<br>
Host: some-website.com<br>
Content-Type: x-www-form-urlencoded<br>
Content-Length: 64<br>
Transfer-Encoding: chunked<br><br>
0<br><br>
GET /admin HTTP/1.1<br>
X-SSL-CLIENT-CN: administrator<br>
Foo: x

Request smuggling có chỉ áp dụng nếu tôi có proxy không?

Không! Vấn đề có thể áp dụng ngay cả khi bạn không sử dụng proxy. Tính năng chính của lỗ hổng là có cơ hội gây nhầm lẫn giữa hai “hệ thống”, cho dù chúng có phải là “máy chủ” đầy đủ hay không.

Đối với các ứng dụng ASP.NET Core, nếu bạn đang làm việc với HttpRequest.Body hoặc HttpRequest.BodyReader, hoặc các phương pháp tương tự khác thì bạn có thể dễ bị tấn công ngay cả khi bạn không sử dụng máy chủ proxy một cách rõ ràng.

Request smuggling trong CVE-2025-55315 hoạt động như thế nào?

Transfer-Encoding: chunked và chunk extensions

Transfer-Encoding: chunked cho phép gửi dữ liệu yêu cầu trong nhiều “chunk”. Mỗi chunk bao gồm một tiêu đề và phần thân. Tiêu đề bao gồm một số byte được định dạng thập lục phân, theo sau là kết thúc dòng
(CRLF).

Chunk extensions là một phần của giao thức HTTP 1.1 cho phép thêm các cặp khóa-giá trị siêu dữ liệu vào từng chunk riêng lẻ. Một chunk extension được chỉ định bằng dấu ; sau độ dài tiêu đề chunk, theo sau là một hoặc nhiều cặp khóa-giá trị ở dạng key=value.

Chunk extensions không hợp lệ với kết thúc dòng không chính xác

Vấn đề là cách các triển khai bỏ qua chúng… Trước khi sửa, khi tìm thấy ; trong tiêu đề chunk, Kestrel sẽ “phân tích” phần mở rộng, nhưng trong thực tế, nó sẽ tìm kiếm ký tự xuống dòng
và sau đó kiểm tra
tiếp theo, bỏ qua mọi thứ ở giữa.

Sự mơ hồ này là cốt lõi của lỗ hổng request smuggling CVE-2025-55315. Sự khác biệt về cách các triển khai proxy và máy chủ xử lý
hoặc
đơn lẻ trong tiêu đề chunk cho phép khai thác request smuggling sử dụng sự mơ hồ này.

Khai thác chunk extensions không hợp lệ cho request smuggling

Kẻ tấn công tạo ra một tiêu đề chunk bị định dạng sai với chunk extension bằng cách gửi 2;
. Dấu ; đảm bảo rằng cả proxy và máy chủ đều coi tiêu đề là chunk extension, nhưng việc sử dụng
thay vì
dẫn đến phân tích khác biệt:

  • Proxy chỉ thấy một yêu cầu duy nhất
  • Máy chủ thấy hai yêu cầu

Lỗ hổng đã được sửa như thế nào?

Giải pháp là ngừng linh hoạt và/hoặc mơ hồ về cách xử lý kết thúc dòng đơn lẻ trong tiêu đề chunk. Trong ASP.NET Core, PR sửa lỗi thực hiện việc này bằng cách kiểm tra rõ ràng bất kỳ kết thúc dòng nào, thay vì chỉ tìm
. Nếu nó tìm thấy kết thúc dòng và nó không nghiêm ngặt là
, thì Kestrel hiện sẽ ném ra KestrelBadHttpRequestException và trả về phản hồi 400.

Bạn nên làm gì?

Tin tốt là có bản sửa lỗi cho ASP.NET Core. Điều quan trọng là cập nhật lên phiên bản ASP.NET Core được hỗ trợ mới nhất càng sớm càng tốt.

Cập nhật phiên bản .NET 8, .NET 9 hoặc .NET 10 của bạn:

  • .NET 10: cập nhật từ 10.0.0-rc1 lên 10.0.0-rc2
  • .NET 9: cập nhật từ 9.0.0-9.0.9 lên 9.0.10
  • .NET 8: cập nhật từ 8.0.0-8.0.20 lên 8.0.21

Nếu bạn đang sử dụng ASP.NET Core trên .NET Framework 2.3, bạn cần cập nhật phiên bản Microsoft.AspNetCore.Server.Kestrel.Core:

  • Cập nhật từ 2.0.0-2.3.0 lên 2.3.6

Các phiên bản cũ hơn của .NET Core? Bạn không thể vá… HeroDevs cung cấp hỗ trợ bổ sung cho các phiên bản .NET không được hỗ trợ, nhưng lỗ hổng này có mặt trong về cơ bản tất cả các phiên bản của .NET Core. Điều tốt nhất cần làm là cập nhật lên phiên bản .NET được hỗ trợ.

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 hay 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 đã được vá. Nếu có, bạn an toàn.

Các nhóm tại HeroDevs đã tái triển khai các bài kiểm tra chức năng từ bản sửa ASP.NET Core gốc dưới dạng ứng dụng console được biên dịch dựa trên nhiều phiên bản ASP.NET Core. Họ đã sử dụng cái này để xác nhận rằng các phiên bản .NET 8-.NET 10 chưa được vá dễ bị tấn công, trong khi các phiên bản đã được vá thì không.

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: Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability. Cảnh báo này cảnh báo về lỗ hổng request smuggling ảnh hưởng đến về 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 về request smuggling để chỉ ra cách sự mơ hồ trong cách phân tích HTTP có thể dẫn đến máy chủ proxy HTTP và máy chủ HTTP xử lý cùng một yêu cầu HTTP theo những cách khác nhau.

Tôi đã thảo luận về một số cách kẻ tấn công có thể khai thác lỗ hổng request smuggling, bao gồm phản chiếu dữ liệu độc hại cho người dùng khác của ứng dụng của bạn, đánh cắp thông tin xác thực hoặc dữ liệu khác từ yêu cầu của client, gọi các endpoint không nên được truy cập công khai và các cuộc tấn công khác.

Tôi đã đi qua lỗ hổng request smuggling cụ thể được xác định trong CVE-2025-55315. Điều này sử dụng sự mơ hồ trong việc phân tích chunk extensions khi gửi các yêu cầu sử dụng mã hóa chuyển chunk. Chunk extensions thường bị tất cả các máy chủ bỏ qua, nhưng việc xử lý linh hoạt có thể dẫn đến xử lý khác biệt giữa proxy và máy chủ, cung cấp con đường cho request smuggling.

Cuối cùng, tôi đã đi qua các bước giảm thiểu bạn nên thực hiện: vá các ứng dụng của bạn. Tôi đã mô tả thông tin chúng tôi hiện có về các máy chủ proxy dễ bị tấn công hoặc đã được vá và cách các phiên bản cũ của ASP.NET Core sẽ không được vá, vì vậy sẽ vẫn dễ bị tấn công.

Chỉ mục