XXE và mặc định của bộ phân tích

XXE khác mọi loại injection khác trong module này ở một điểm quan trọng: bạn không nối chuỗi gì cả. Không có dòng code nào của bạn ghép dữ liệu vào cú pháp. Bạn chỉ gọi XmlDocument.Load(stream) — và lỗ hổng đến từ mặc định của thư viện.

Nguyên nhân là một tính năng có thật của XML: external entity. Một tài liệu XML được phép khai một entity trỏ tới một tài nguyên bên ngoài, và một parser tuân thủ chuẩn thì đi lấy tài nguyên đó.

<?xml version="1.0"?><!DOCTYPE r [  <!ENTITY x SYSTEM "file:///etc/passwd">]><r>&x;</r>

Parser đọc file đó và đặt nội dung vào chỗ &x;. Nếu ứng dụng của bạn echo lại nội dung XML — hoặc chỉ cần đưa nó vào một thông báo lỗi — thì /etc/passwd đã ra ngoài.

Ba hệ quả, xếp theo mức nghiêm trọng, và hệ quả thứ ba là hệ quả người ta không nghĩ tới:

Hệ quả thứ hai là chỗ XXE và SSRF gặp nhau, và nó nghiêm trọng hơn đọc file trong môi trường cloud: parser gọi được vào metadata endpoint của cloud provider, thứ mà kẻ tấn công không gọi được từ ngoài.

Tin tốt về .NET, và đây là điều đáng biết chính xác: từ .NET Framework 4.5.2 trở lên và trong toàn bộ .NET Core/.NET 5+, XmlDocument, XmlReader và XDocument an toàn theo mặc định — DtdProcessing là Prohibit và XmlResolver là null. Nghĩa là XXE trong .NET hiện đại gần như luôn là kết quả của việc ai đó bật nó lên, thường vì một file XML hợp lệ cần DTD và cách nhanh nhất để nó chạy là mở hết ra.

Đó là lý do bài này tập trung vào việc đọc cấu hình thay vì tìm chỗ nối chuỗi.