Zapobieganie XML External Entities (XXE) w PHP

Krótko: XXE w PHP zapobiegasz, ładując XML z obcych źródeł bez opcji LIBXML_NOENT, LIBXML_DTDLOAD i LIBXML_DTDVALID, odrzucając dokumenty z własnym DTD i ustawiając entity loader, który odmawia zewnętrznych zasobów. Od libxml 2.9.0 PHP domyślnie nie zastępuje już encji, dlatego libxml_disable_entity_loader() jest od PHP 8.0 przestarzała. Od PHP 8.4 z libxml 2.13 dostępna jest dodatkowo LIBXML_NO_XXE.

Stara luka, która nie znika

XML External Entities, w skrócie XXE, uchodzą u wielu programistów za temat załatwiony. PHP wyłączyło domyślnie ładowanie zewnętrznych encji we współczesnych wersjach libxml, a dawna funkcja ochronna została oznaczona w PHP 8.0 jako przestarzała. Mimo to luki XXE nadal pojawiają się podczas kontroli.

Przyczyną jest prawie zawsze jedna z trzech sytuacji: ktoś ustawił opcję, aby rozwiązać problem z importem, i tym samym ponownie włączył zastępowanie encji. Biblioteka robi to wewnętrznie. Albo aplikacja działa na starym systemie, którego PHP zbudowano z bardzo starą libxml.

XXE jest niebezpieczne, ponieważ parser XML doładowuje wtedy treści, do których dokument tylko się odwołuje: lokalne pliki lub adresy w sieci. Możliwe skutki to odczyt plików konfiguracyjnych, żądania do systemów wewnętrznych podobnie jak w SSRF oraz przeciążenie serwera.

Co obowiązuje od libxml 2.9 i PHP 8.0

Podręcznik PHP opisuje sytuację tak: od libxml 2.9.0 zastępowanie encji jest domyślnie wyłączone. Zewnętrznych encji nie trzeba więc osobno wyłączać, chyba że wewnętrzne odwołania do encji mają być rozwiązywane za pomocą określonych opcji. Z tego wynika poniższe zestawienie:

Mylna nazwa LIBXML_NOENT to znana pułapka: brzmi jak „bez encji”, a powoduje coś odwrotnego.

Dla programistów oznacza to: ryzykowne nie jest samo ładowanie XML, lecz każde miejsce, które świadomie zmienia zachowanie domyślne. Wyszukanie tych stałych w kodzie jest dlatego najszybszą drogą do wstępnej oceny, jeszcze przed jakąkolwiek pracochłonną kontrolą.

Skuteczna obrona przed XXE w PHP: wzorzec dla DOMDocument

Poniższy przykład łączy kilka warstw ochrony. Ustawia entity loader, który odmawia każdego zewnętrznego zasobu, ładuje bez ryzykownych opcji i odrzuca dokumenty z własnym DTD:

<?php
declare(strict_types=1);

function ladeFremdesXml(string $xml): DOMDocument
{
    // Zasadniczo odmawiać zewnętrznych zasobów
    libxml_set_external_entity_loader(
        static fn (?string $public, string $system, array $context) => null
    );

    $optionen = LIBXML_NONET;
    if (defined('LIBXML_NO_XXE')) {
        $optionen |= LIBXML_NO_XXE;
    }

    $vorher = libxml_use_internal_errors(true);
    $dom = new DOMDocument();
    $ok = $dom->loadXML($xml, $optionen);
    libxml_use_internal_errors($vorher);

    if (!$ok) {
        throw new InvalidArgumentException('XML ungültig.');
    }
    if ($dom->doctype !== null) {
        throw new InvalidArgumentException('Dokumente mit DTD werden nicht angenommen.');
    }
    return $dom;
}

Według podręcznika PHP wartość zwracana null w loaderze blokuje ładowanie zewnętrznego zasobu. OWASP zwraca uwagę, że nie wystarczy przekazać null bezpośrednio do libxml_set_external_entity_loader(); potrzebna jest funkcja zwracająca null. Dla SimpleXML i XMLReader obowiązują te same opcje. Wszędzie tam, gdzie to możliwe, OWASP zaleca całkowite odrzucanie DTD.

Znajdowanie ukrytych wejść XML

Wiele aplikacji przetwarza więcej XML, niż myślą ich programiści. Przejdź przez tę listę:

1. Interfejsy: klienci i serwery SOAP, XML-RPC, usługi płatności i wysyłki z odpowiedziami XML.
2. Logowanie: Single sign-on z SAML opiera się na dokumentach XML pochodzących z zewnątrz.
3. Importy: dane produktów, kanały, mapy witryn, formaty katalogów.
4. Uploady: obrazy SVG to XML; formaty Office, takie jak DOCX i XLSX, składają się wewnętrznie z plików XML.
5. Biblioteki: pakiety Composera do dokumentów, arkuszy lub SAML, które wewnętrznie używają libxml.

W kodzie pomagają dwa wyszukiwania:

grep -rnE "LIBXML_(NOENT|DTDLOAD|DTDVALID|PARSEHUGE)" src/ vendor/ --include="*.php"
grep -rnE "(loadXML|simplexml_load_(string|file)|XMLReader|->load\()" src/ --include="*.php"

Znaleziska w vendor/ nie są powodem do paniki, ale są okazją do sprawdzenia wersji biblioteki i komunikatów bezpieczeństwa.

W przypadku uploadów SVG XXE jest tylko jednym z kilku ryzyk, ponieważ pliki SVG mogą zawierać także skrypty. Jeśli Państwa aplikacja nie potrzebuje tego formatu bezwzględnie, w ogóle nie dopuszczaj go do uploadów. W przeciwnym razie przetwarzaj SVG wyłącznie według bezpiecznego wzorca powyżej i dostarczaj pliki tak, aby przeglądarka nie wykonywała zawartych skryptów.

Zwróć też uwagę na komunikaty o błędach. Jeśli aplikacja zwraca użytkownikom komunikaty libxml bez filtrowania, mogą w nich znaleźć się fragmenty przetwarzanej treści. Błędy należą do logu, użytkownik otrzymuje ogólny komunikat; w powyższym przykładzie libxml_use_internal_errors(true) sprawia, że ostrzeżenia nie trafiają do wyjścia. Ogranicz ponadto rozmiar otrzymywanych dokumentów XML, zanim parser w ogóle je zobaczy.

Stare systemy: kiedy brakuje ochrony domyślnej

Ochrona wynikająca z zachowania domyślnego zależy od wersji libxml, z którą zbudowano PHP. To, jaka wersja działa, pokazuje php -r 'echo LIBXML_DOTTED_VERSION, PHP_EOL;' w wierszu poleceń albo wynik phpinfo() w chronionym środowisku. Sprawdź wartość dla każdej wersji PHP na serwerze, ponieważ CLI i serwer WWW mogą używać różnych buildów. Obrazy kontenerów przynoszą własną libxml; tam sprawdzaj w działającym kontenerze, a nie na hoście.

Szczególnie narażone są systemy, które i tak działają na starych wersjach PHP. Dla PHP 8.1 i starszych po PHP2Shell nie ma już oficjalnych aktualizacji projektu PHP; co to oznacza, opisuje artykuł PHP 8.1 i starsze: co teraz obowiązuje. Stary system z przestarzałą libxml i otwartymi lukami interpretera należy nie tylko zabezpieczyć w kodzie, ale zmigrować. Pokrewne ryzyka przy przetwarzaniu obcych danych opisuje artykuł Niebezpieczna deserializacja w PHP, a pobieranie celów wewnętrznych artykuł Zapobieganie Server-Side Request Forgery w PHP.

Jak konkretnie pomaga PHP SOS?

• Znajdujemy wszystkie miejsca, w których Państwa aplikacja i jej biblioteki przetwarzają XML z obcych źródeł.
• Usuwamy ryzykowne opcje parsera i wprowadzamy centralną, zabezpieczoną funkcję ładującą.
• Sprawdzamy wersje libxml i PHP na wszystkich serwerach i planujemy migrację starych systemów.
• Testujemy zmiany nieszkodliwymi dokumentami kontrolnymi i dokumentujemy wynik.

Kontrolę własnego oprogramowania opisuje usługa audyt bezpieczeństwa i test penetracyjny.

Częste pytania

Źródła

• Podręcznik PHP: libxml_disable_entity_loader
• Podręcznik PHP: stałe libxml
• OWASP XML External Entity Prevention Cheat Sheet (ściągawka o zapobieganiu XXE)