XML External Entity (XXE) - Czy Twoje dane są bezpieczne?

Czym jest XML External Entity (XXE) i dlaczego to wciąż poważne zagrożenie?

Podatność XML External Entity (XXE) stanowi poważne ryzyko dla aplikacji, które nieprawidłowo obsługują dane wejściowe w formacie XML. Jest to luka bezpieczeństwa polegająca na tym, że atakujący może wstrzyknąć do dokumentu XML odwołanie do zewnętrznej encji, która następnie jest przetwarzana przez parser XML po stronie serwera. W efekcie parser wykonuje niezamierzone operacje, które mogą mieć katastrofalne skutki dla bezpieczeństwa aplikacji i infrastruktury. Główną przyczyną tej podatności jest fakt, że wiele parserów XML domyślnie aktywuje funkcje zgodne ze specyfikacją XML, które mogą być wykorzystane w celach złośliwych, takie jak zewnętrzne definicje typu dokumentu (DTD).

Problem ten nie jest jedynie teoretyczny. W ostatnich latach odnotowano liczne przypadki wykorzystania luk XXE w popularnym oprogramowaniu. W 2023 roku zidentyfikowano ją w parserze oprogramowania antywirusowego ClamAV (CVE-2023-20052). Kolejny przykład to podatność w narzędziu do zarządzania usługami IT SysAid, odkryta w 2025 roku. Również w 2024 roku załatano lukę XXE w Microsoft SharePoint (CVE-2024-30043), która pozwalała na odczyt plików z systemu i ataki typu SSRF. Te przykłady jasno pokazują, że XXE jest wciąż aktualnym i istotnym zagrożeniem.

Encje w XML: Od użytecznej funkcji do wektora ataku

W języku XML encje to mechanizm pozwalający na definiowanie skrótów lub zastępowanie specjalnych znaków. Mogą być używane do reprezentowania znaków, które mają specjalne znaczenie w składni XML (np. `<` jako `<`), do tworzenia czytelnych aliasów dla długich ciągów tekstowych, a także do włączania treści z zewnętrznych źródeł. Ta elastyczność sprawia, że encje są potężnym narzędziem. Jednakże, gdy parser XML jest skonfigurowany do przetwarzania zewnętrznych encji, czyli takich, które odwołują się do zasobów spoza przetwarzanego dokumentu XML na przykład plików na serwerze lub zasobów sieciowych stają się one potencjalnym wektorem ataku. Atakujący może wykorzystać tę funkcjonalność do skierowania parsera na niepożądane cele.

Dlaczego domyślna konfiguracja parsera XML może narazić Cię na ryzyko?

Wiele popularnych parserów XML domyślnie jest skonfigurowanych w sposób, który może prowadzić do podatności na ataki XXE. Producenci oprogramowania często stawiają na pełną zgodność ze specyfikacją XML, co oznacza, że domyślnie włączone są funkcje takie jak przetwarzanie zewnętrznych definicji typu dokumentu (DTD) oraz zewnętrznych encji. Chociaż zapewnia to maksymalną elastyczność i zgodność z różnymi dokumentami XML, jednocześnie otwiera drzwi dla atakujących, jeśli aplikacja przetwarza dane pochodzące z niezaufanych źródeł. Brak świadomości tych domyślnych ustawień i poleganie na nich bez odpowiedniej konfiguracji stanowi jedno z głównych źródeł podatności XXE.

Realne skutki ataków XXE: Utrata danych, przejęcie serwera i straty finansowe

Ataki wykorzystujące podatność XXE mogą prowadzić do bardzo poważnych konsekwencji, które bezpośrednio wpływają na bezpieczeństwo danych i stabilność działania aplikacji. Oto główne typy tych ataków:

• Ujawnienie plików lokalnych: Atakujący może wykorzystać mechanizm zewnętrznych encji do odczytania dowolnych plików znajdujących się na serwerze, do których aplikacja ma uprawnienia dostępu. Może to obejmować pliki konfiguracyjne zawierające wrażliwe dane, hasła użytkowników, klucze prywatne do certyfikatów SSL, a nawet kod źródłowy aplikacji.
• Server-Side Request Forgery (SSRF): Dzięki XXE aplikacja może zostać zmuszona do wykonania żądań sieciowych do innych systemów wewnątrz infrastruktury sieciowej. Pozwala to atakującemu na skanowanie wewnętrznych portów, interakcję z usługami dostępnymi tylko w sieci lokalnej, a nawet na atakowanie innych wewnętrznych serwerów.
• Odmowa usługi (DoS): Znany jako atak "Billion Laughs", polega na stworzeniu zagnieżdżonych definicji encji, które podczas przetwarzania prowadzą do wykładniczego wzrostu ilości danych. Parser XML próbuje przetworzyć ogromną liczbę danych, co szybko wyczerpuje zasoby serwera (pamięć i moc obliczeniową), prowadząc do zawieszenia aplikacji lub całego systemu.
• Zdalne wykonanie kodu (RCE): W niektórych, bardziej zaawansowanych scenariuszach, w zależności od specyfiki technologii użytej w aplikacji i konfiguracji serwera, podatność XXE może zostać wykorzystana do zdalnego wykonania kodu na serwerze. Jest to najbardziej krytyczny skutek, który może prowadzić do pełnego przejęcia kontroli nad systemem.

Anatomia ataku XXE: Jak hakerzy wykorzystują tę podatność krok po kroku?

Zrozumienie, jak dokładnie działają ataki XXE, jest kluczowe do skutecznej obrony. Hakerzy wykorzystują specyficzne konstrukcje w dokumentach XML, aby manipulować parserem i skłonić go do wykonania niepożądanych operacji. Proces ten zazwyczaj obejmuje stworzenie złośliwego ładunku XML, który zawiera odwołanie do zewnętrznej encji, a następnie dostarczenie tego dokumentu do aplikacji, która go przetworzy. Sposób, w jaki atakujący konstruuje ten ładunek i jakie techniki stosuje, zależy od konkretnego celu ataku.

Klasyczny atak XXE: Jak wykraść pliki z serwera (np. /etc/passwd)?

Jednym z najczęstszych i najbardziej niebezpiecznych zastosowań XXE jest kradzież wrażliwych plików z systemu plików serwera. Atakujący tworzy dokument XML, który definiuje zewnętrzną encję odwołującą się do pliku systemowego za pomocą prefiksu `file:///`. Gdy parser przetworzy taki dokument, spróbuje odczytać zawartość wskazanego pliku i podstawić ją w miejsce odwołania do encji. Jeśli aplikacja nieprawidłowo obsługuje dane wyjściowe, zawartość pliku może zostać ujawniona atakującemu.

Oto przykład takiego ataku, który ma na celu odczytanie pliku `/etc/passwd` na systemach Linux:

]>
&xxe;

W tym przykładzie, `&xxe;` zostanie zastąpione przez zawartość pliku `/etc/passwd`, a wynikowy dokument zostanie przetworzony przez aplikację. Jeśli aplikacja zwraca wynik przetwarzania do użytkownika, atakujący może zobaczyć zawartość pliku.

Atak SSRF przez XXE: Jak zmusić serwer do skanowania Twojej sieci wewnętrznej?

Ataki Server-Side Request Forgery (SSRF) przy użyciu XXE pozwalają atakującemu na wykorzystanie podatnej aplikacji jako proxy do wykonywania żądań do wewnętrznych zasobów sieciowych. Zamiast odwoływać się do lokalnego pliku, zewnętrzna encja wskazuje na adres URL w sieci wewnętrznej. Aplikacja serwera, przetwarzając ten XML, wysyła żądanie HTTP do wskazanego adresu, co może ujawnić informacje o wewnętrznej infrastrukturze lub pozwolić na interakcję z usługami, które nie powinny być dostępne z zewnątrz.

Przykład takiego ataku wygląda następująco:

]>
&xxe;

W tym przypadku, serwer ofiary spróbuje połączyć się z adresem `http://192.168.1.1:8080/admin`. Atakujący może wykorzystać to do skanowania sieci, identyfikacji aktywnych usług lub próby interakcji z panelami administracyjnymi dostępnymi tylko w sieci lokalnej.

Atak "Billion Laughs": Jak prosta pętla w XML może zablokować Twoją aplikację?

Atak typu "Billion Laughs" (znany również jako bomba XML) to klasyczny przykład wykorzystania XXE do przeprowadzenia ataku odmowy usługi (DoS). Polega on na zdefiniowaniu serii zagnieżdżonych encji, gdzie każda kolejna definicja rozszerza poprzednią w sposób wykładniczy. Parser XML, próbując przetworzyć taką konstrukcję, musi wielokrotnie rozwinąć te encje, co prowadzi do gwałtownego wzrostu ilości danych i błyskawicznego zużycia zasobów serwera, takich jak pamięć operacyjna i moc obliczeniowa.

Oto przykład kodu XML demonstrującego ten mechanizm:

 <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
&lol9;

Przetworzenie tego dokumentu przez parser XML spowoduje wygenerowanie ogromnej ilości tekstu ("lol" powtórzone miliardy razy), co niemal gwarantuje wyczerpanie zasobów serwera i awarię aplikacji.

Blind XXE: Gdy atakujący nie widzi odpowiedzi, ale i tak kradnie dane

W scenariuszach "Blind XXE" atakujący nie otrzymuje bezpośredniej odpowiedzi z parsowanego dokumentu XML. Oznacza to, że klasyczne metody wycieku danych, takie jak odczyt plików czy wyniki zapytań sieciowych, nie działają, ponieważ aplikacja nie zwraca ich do użytkownika. W takich sytuacjach atakujący musi zastosować bardziej zaawansowane techniki. Jedną z nich jest wykorzystanie zewnętrznego DTD hostowanego na serwerze kontrolowanym przez atakującego. Aplikacja ofiary, przetwarzając złośliwy XML, wysyła żądanie do tego zewnętrznego DTD. W odpowiedzi DTD może zawierać instrukcje, które spowodują, że serwer ofiary wyśle dane (np. zawartość pliku) jako żądanie HTTP na serwer atakującego. W ten sposób dane są "wyprowadzane" poza normalny kanał komunikacji.

Klucz do bezpieczeństwa: Jak skutecznie bronić się przed atakami XXE?

Skuteczna ochrona przed atakami XXE opiera się przede wszystkim na właściwej konfiguracji parserów XML oraz na świadomości programistów na temat potencjalnych zagrożeń. Nie wystarczy polegać na domyślnych ustawieniach; konieczne jest aktywne zabezpieczanie aplikacji. Najlepsze praktyki obejmują wyłączanie niepotrzebnych funkcji parsera i stosowanie mechanizmów walidacji danych.

Najważniejsza zasada: Całkowite wyłączenie DTD jako najskuteczniejsza obrona

Najbardziej fundamentalnym i najskuteczniejszym sposobem zapobiegania większości ataków XXE jest całkowite wyłączenie obsługi zewnętrznych definicji typu dokumentu (DTD) w konfiguracji parsera XML. DTD są głównym źródłem podatności na XXE, ponieważ to one pozwalają na definiowanie i ładowanie zewnętrznych encji. Jeśli całkowite wyłączenie DTD nie jest możliwe ze względu na specyficzne wymagania aplikacji, kolejnym krokiem jest przynajmniej wyłączenie obsługi zewnętrznych encji oraz zewnętrznych deklaracji DTD. Jest to kluczowy krok, który znacząco redukuje powierzchnię ataku.

Bezpieczna konfiguracja parsera XML w praktyce: Przykłady kodu

Poniżej przedstawiono przykłady bezpiecznej konfiguracji parserów XML dla popularnych języków programowania. Pokazują one, jak można wyłączyć funkcje podatne na ataki XXE, co jest niezbędne do zabezpieczenia aplikacji.

Zabezpieczanie aplikacji w Javie (JAXP, DOM4J, StAX)

W Javie, aby zabezpieczyć aplikacje przed XXE, należy odpowiednio skonfigurować fabryki parserów. Oto przykłady dla najczęściej używanych API:

// JAXP DocumentBuilderFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// Wyłącza ładowanie DTD, co jest kluczowe dla zapobiegania XXE
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
// Wyłącza przetwarzanie zewnętrznych encji ogólnych
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
// Wyłącza przetwarzanie zewnętrznych encji parametrów
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
// Wyłącza ładowanie zewnętrznych DTD w trybie nie-walidującym
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
// Wyłącza XInclude, które może być również wykorzystane w atakach
dbf.setXIncludeAware(false);
// Dodatkowe zabezpieczenie: zapobiega rozwijaniu referencji do encji
dbf.setExpandEntityReferences(false); // JAXP SAXParserFactory
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
spf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); // JAXP XMLInputFactory (StAX)
XMLInputFactory xif = XMLInputFactory.newInstance();
// Wyłącza obsługę DTD
xif.setProperty(XMLInputFactory.SUPPORT_DTD, false);
// Wyłącza obsługę zewnętrznych encji
xif.setProperty("javax.xml.stream.isSupportingExternalEntities", false);

Dobre praktyki dla programistów .NET (XmlReader, DocumentBuilder)

W środowisku .NET kluczowe jest skonfigurowanie `XmlReaderSettings` lub `XmlDocument` w sposób uniemożliwiający przetwarzanie zewnętrznych zasobów. Oto przykłady:

// XmlReader
XmlReaderSettings settings = new XmlReaderSettings();
// Ustawia przetwarzanie DTD na Prohibit, co zapobiega ładowaniu zewnętrznych DTD.
// Można również użyć DtdProcessing.Ignore, jeśli nie potrzebujemy walidacji DTD.
settings.DtdProcessing = DtdProcessing.Prohibit;
// Wyłącza rozwiązywanie zewnętrznych zasobów, w tym encji i DTD.
settings.XmlResolver = null; using (XmlReader reader = XmlReader.Create(stream, settings))
{ // Przetwarzanie XML
} // XmlDocument
XmlDocument doc = new XmlDocument();
// Ustawienie XmlResolver na null wyłącza rozwiązywanie zewnętrznych zasobów,
// co zapobiega atakom XXE.
doc.XmlResolver = null;
// Uwaga: W starszych wersjach .NET mogło być potrzebne jawne ustawienie ProhibitDtd = true;
// W nowszych wersjach, ustawienie XmlResolver na null jest wystarczające.

Ochrona przed XXE w aplikacjach PHP (libxml)

W PHP, głównym narzędziem do przetwarzania XML jest biblioteka `libxml`. Aby zabezpieczyć aplikacje, należy wyłączyć ładowanie encji zewnętrznych za pomocą funkcji `libxml_disable_entity_loader()`.

// Przed parsowaniem XML, wyłączamy ładowanie encji zewnętrznych.
libxml_disable_entity_loader(true); // Przykład użycia z SimpleXML
$xml = simplexml_load_string($unsafe_xml_string); // Przykład użycia z DOMDocument
$dom = new DOMDocument();
$dom->loadXML($unsafe_xml_string);

Wywołanie `libxml_disable_entity_loader(true)` jest kluczowe i powinno być wykonane przed jakimkolwiek parsowaniem niezaufanego kodu XML.

Bezpieczne przetwarzanie XML w Pythonie

W Pythonie, biblioteki takie jak `lxml` i `xml.etree.ElementTree` oferują mechanizmy zabezpieczające przed XXE. W nowszych wersjach Pythona, `ElementTree` jest domyślnie bezpieczniejsze.

# lxml
from lxml import etree
# resolve_entities=False zapobiega przetwarzaniu zewnętrznych encji.
# no_network=True dodatkowo ogranicza możliwość wykonywania żądań sieciowych.
parser = etree.XMLParser(resolve_entities=False, no_network=True)
root = etree.fromstring(unsafe_xml_string, parser) # xml.etree.ElementTree (domyślnie bezpieczne od Python 2.7.9 i 3.4)
import xml.etree.ElementTree as ET
# W nowszych wersjach ElementTree domyślnie nie przetwarza zewnętrznych encji.
# Jeśli używasz starszej wersji, rozważ inną bibliotekę lub walidację.
root = ET.fromstring(unsafe_xml_string)

Ważne jest, aby upewnić się, że używana wersja Pythona i bibliotek jest aktualna i posiada wbudowane zabezpieczenia.

Walidacja vs. parsowanie: Rola schematów XSD w ograniczaniu ryzyka

Walidacja XML za pomocą schematów XSD (XML Schema Definition) jest ważnym elementem zapewnienia jakości i struktury danych, ale nie jest bezpośrednią obroną przed atakami XXE. Schematy XSD definiują dozwoloną strukturę, typy danych i ograniczenia zawartości dokumentu XML. Dzięki walidacji można odrzucić dokumenty, które nie pasują do zdefiniowanego schematu, co może pomóc w ograniczeniu ryzyka poprzez odrzucenie nieprawidłowych lub złośliwych danych wejściowych. Jednakże, atakujący mogą nadal próbować wykorzystać XXE nawet w poprawnie ustrukturyzowanych dokumentach XML, jeśli parser jest podatny. Dlatego walidacja XSD powinna być traktowana jako dodatkowa warstwa obrony, a nie jako substytut bezpiecznej konfiguracji parsera.

Gdzie szukać podatności XXE w swojej infrastrukturze?

Podatności XXE mogą czaić się w miejscach, których początkowo nie podejrzewamy. Oprócz oczywistego przetwarzania plików XML, wiele formatów plików i protokołów opiera się na XML-u w swojej wewnętrznej strukturze, co czyni je potencjalnymi punktami wejścia dla ataków XXE. Świadomość tych mniej oczywistych wektorów jest kluczowa dla kompleksowego zabezpieczenia aplikacji.

Punkty wejścia, o których mogłeś nie pomyśleć: Przesyłanie plików SVG, DOCX i SOAP

Oto kilka mniej oczywistych punktów wejścia, które mogą być podatne na ataki XXE:

• Pliki SVG: Grafiki wektorowe Scalable Vector Graphics (SVG) są w rzeczywistości dokumentami XML. Mogą one zawierać zewnętrzne encje, które zostaną przetworzone przez aplikacje renderujące lub analizujące pliki SVG, co może prowadzić do ataków XXE.
• Pliki DOCX, XLSX, PPTX: Nowoczesne formaty plików pakietu Microsoft Office (oraz ich odpowiedniki w innych pakietach) to w rzeczywistości archiwa ZIP zawierające wiele plików XML. Dokumenty te mogą zawierać złośliwe encje, które zostaną aktywowane podczas otwierania lub przetwarzania plików przez aplikacje pakietu Office lub inne narzędzia obsługujące te formaty.
• Wiadomości SOAP: Protokół SOAP (Simple Object Access Protocol) jest szeroko stosowany w usługach webowych i opiera się w całości na XML-u do formatowania wiadomości. Aplikacje komunikujące się za pomocą SOAP są częstym celem ataków XXE, ponieważ przetwarzają zewnętrzne dane XML, które mogą być manipulowane przez atakujących.

Narzędzia i techniki do wykrywania XXE: Od analizy kodu po testy penetracyjne

Wykrywanie podatności XXE wymaga zastosowania różnorodnych narzędzi i technik, które obejmują zarówno analizę statyczną, jak i dynamiczną, a także testy manualne:

• Statyczna analiza kodu (SAST): Narzędzia SAST skanują kod źródłowy aplikacji w poszukiwaniu potencjalnych luk bezpieczeństwa, w tym nieprawidłowej konfiguracji parserów XML. Pomagają one zidentyfikować miejsca, gdzie obsługa DTD lub zewnętrznych encji nie jest wyłączona.
• Dynamiczna analiza bezpieczeństwa aplikacji (DAST): Narzędzia DAST, takie jak OWASP ZAP czy Burp Suite, testują działającą aplikację, wysyłając do niej złośliwe ładunki i analizując odpowiedzi. Mogą one symulować ataki XXE, wysyłając specjalnie spreparowane dokumenty XML.
• Testy penetracyjne: Specjaliści ds. bezpieczeństwa przeprowadzają ręczne testy penetracyjne, symulując realistyczne scenariusze ataków. Pozwala to na identyfikację luk, które mogą zostać pominięte przez narzędzia automatyczne, oraz na ocenę rzeczywistego wpływu podatności.
• Przegląd kodu: Manualna weryfikacja kodu źródłowego aplikacji przez doświadczonych programistów lub audytorów bezpieczeństwa jest niezwykle ważna. Pozwala na dokładne sprawdzenie konfiguracji parserów XML i identyfikację potencjalnych ryzyk.

Myśl jak haker, chroń jak ekspert: Kluczowe strategie obronne w pigułce

Podsumowując, obrona przed atakami XXE wymaga proaktywnego podejścia i stosowania się do najlepszych praktyk. Kluczowe jest zrozumienie, że domyślne konfiguracje parserów XML często nie są bezpieczne, a odpowiedzialność za zabezpieczenie aplikacji spoczywa na programistach. Poniższa lista kontrolna stanowi zbiór najważniejszych kroków, które należy podjąć, aby zminimalizować ryzyko.

Checklista bezpieczeństwa: 5 kroków do weryfikacji ochrony przed XXE

1. Czy wszystkie parsery XML w aplikacji mają wyłączoną obsługę zewnętrznych DTD i encji? To podstawowy i najważniejszy krok.
2. Czy aplikacja waliduje wszystkie dane wejściowe XML za pomocą schematów XSD? Walidacja XSD stanowi dodatkową warstwę obrony.
3. Czy używane biblioteki i frameworki do przetwarzania XML są aktualne i wolne od znanych podatności? Regularne aktualizacje są kluczowe.
4. Czy punkty wejścia, które przetwarzają pliki takie jak SVG, DOCX, XLSX lub wiadomości SOAP, są odpowiednio zabezpieczone? Należy pamiętać o mniej oczywistych wektorach ataków.
5. Czy regularnie przeprowadzane są testy bezpieczeństwa (SAST, DAST, testy penetracyjne) w celu wykrycia potencjalnych luk XXE? Ciągłe monitorowanie i testowanie jest niezbędne.

Przeczytaj również: Co to trackery internetowe - jak działają i chroń prywatność

Dlaczego regularne aktualizacje bibliotek i frameworków są krytyczne?

Utrzymywanie aktualnych wersji bibliotek i frameworków używanych do przetwarzania XML jest absolutnie kluczowe dla bezpieczeństwa. Deweloperzy tych bibliotek stale identyfikują i łatają znane luki bezpieczeństwa, w tym te związane z podatnościami XXE. Nieaktualne komponenty mogą zawierać znane defekty, które atakujący mogą łatwo wykorzystać. Regularne aktualizacje zapewniają, że aplikacja korzysta z najnowszych poprawek bezpieczeństwa i jest lepiej chroniona przed znanymi zagrożeniami.