Biztonsági kockázatok az XML feldolgozás során

Az Extensible Markup Language (XML) mára az informatikai rendszerek közötti adatcsere és konfiguráció egyik alapkövévé vált. Rugalmasságának, olvashatóságának és szabványosított felépítésének köszönhetően széles körben alkalmazzák webes szolgáltatásokban (REST, SOAP), dokumentumkezelésben, adatbázis-integrációban és számos más területen. Ugyanakkor, mint minden technológia, az XML feldolgozás is rejt magában jelentős biztonsági kockázatokat, melyek megfelelő kezelés nélkül súlyos adatszivárgáshoz, szolgáltatásmegtagadáshoz (DoS) vagy akár teljes rendszerkompromittáláshoz vezethetnek.

Ebben a cikkben részletesen áttekintjük azokat a leggyakoribb XML biztonsági sebezhetőségeket, amelyekkel a fejlesztőknek és a rendszergazdáknak szembesülniük kell. Megvizsgáljuk a támadások módját és bemutatjuk a hatékony védekezési stratégiákat, hogy rendszerei a lehető legbiztonságosabban működjenek.

Miért Jelent Kockázatot az XML Feldolgozás?

Az XML, mint adatábrázoló nyelv, önmagában nem sérülékeny. A problémák forrása jellemzően az XML dokumentumok feldolgozásáért felelős parserek, illetve azok konfigurációja, valamint a fejlesztők által alkalmazott implementációs minták. Az XML parserek gyakran komplex funkciókat kínálnak (pl. entitások feloldása, DTD feldolgozás, XSLT transzformáció), melyek rosszindulatú input esetén kihasználhatóvá válnak. A támadók a specifikáció adta lehetőségeket használják ki arra, hogy váratlan módon befolyásolják a parser működését, vagy hozzáférjenek a mögöttes rendszer erőforrásaihoz.

A Leggyakoribb XML Biztonsági Sebezhetőségek

1. XML External Entity (XXE) Injection

Az XXE injection (külső XML entitás injektálás) az egyik legismertebb és legveszélyesebb XML sebezhetőség. Akkor fordul elő, ha egy XML parser úgy van konfigurálva, hogy feldolgozza a külső entitásokat egy DTD-ben (Document Type Definition), és a támadó kontrollálja az XML inputot.

Hogyan működik?

Az XML DTD-k lehetővé teszik, hogy entitásokat definiáljunk, amelyek hivatkozhatnak külső forrásokra (fájlokra, URL-ekre). Ha a parser ezeket az entitásokat feloldja és feldolgozza, a támadó a következőkre képes:

Helyi fájlok olvasása: A támadó beolvashat érzékeny rendszerszintű fájlokat (pl. /etc/passwd, konfigurációs fájlokat) az entitáson keresztül. Példa: <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]><foo>&xxe;</foo>
SSRF (Server-Side Request Forgery) támadások: A szerver képessé válik arra, hogy belső vagy külső hálózatokon lévő erőforrásokat kérjen le a támadó nevében. Ez lehetővé teszi belső rendszerek feltérképezését, port szkennelését vagy belső szolgáltatások támadását. Példa: <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://intranet.example.com/admin" > ]><foo>&xxe;</foo>
Szolgáltatásmegtagadás (DoS): Az entitások végtelen rekurzív feloldásával a támadó erőforrás-kimerülést okozhat a szerveren. Lásd az „XML Bomb” részt alább.

Védekezés XXE ellen:

A leghatékonyabb védekezés az XXE támadások ellen az, ha teljesen letiltjuk a DTD-ket és a külső entitások feldolgozását az XML parserben. A legtöbb modern XML könyvtár és framework biztosít erre konfigurációs lehetőségeket. Például Java-ban a setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true) beállítása, vagy az XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES és XMLInputFactory.SUPPORT_DTD kikapcsolása.

2. XML Bomb (Milliárd nevetés támadás)

Az XML Bomb vagy „Billion Laughs” támadás egy speciális DoS támadás, amely az entitások rekurzív definícióját használja ki az XML-ben. A célja, hogy egy nagyon kis méretű XML dokumentummal olyan hatalmas mennyiségű erőforrást (memóriát, CPU-t) foglaljon le, hogy a parser összeomoljon, vagy a rendszer leálljon.

Hogyan működik?

A támadás egy nested entitás definícióra épül. Például:

<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!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;">
]>
<lolz>&lol6;</lolz>

Ez a néhány soros XML dokumentum exponenciálisan bővíti a „lol” karakterláncot. Míg a bemenet csak néhány kilobájt, a parser megpróbálja feloldani az entitásokat, és a végső kimenet gigabájtnyi, vagy akár terabájtnyi méretű is lehetne, mielőtt a memória kimerülne. Ez gyorsan vezet DoS-hoz.

Védekezés XML Bomb ellen:

Az XML Bomb támadások megelőzésére több stratégia is létezik:

Entitás kiterjesztés korlátozása: A legtöbb parser konfigurálható úgy, hogy korlátozza az entitások mélységét és/vagy az expandált karakterek számát.
XML input méretkorlátja: Állítson be maximális méretet a bejövő XML dokumentumok számára, mielőtt azok feldolgozásra kerülnének.
Szekvenciális (stream) feldolgozás: Amennyiben lehetséges, használjon SAX-alapú (Simple API for XML) vagy StAX-alapú (Streaming API for XML) parsereket, amelyek sorban dolgozzák fel az XML-t, anélkül, hogy az egészet memóriába töltenék. Ezáltal könnyebben lehet monitorozni az erőforrás-használatot és időben megszakítani a feldolgozást.
DTD letiltása: Mint az XXE esetében, a DTD-k teljes letiltása is megakadályozza az ilyen típusú támadásokat.

3. XPath Injection

Az XPath injection hasonlóan működik, mint az SQL injection, de az XML dokumentumok lekérdezésére használt XPath kifejezéseket manipulálja. Ha egy alkalmazás felhasználói input alapján dinamikusan épít fel XPath lekérdezéseket, és nem megfelelően validálja az inputot, a támadó megváltoztathatja a lekérdezés logikáját.

Hogyan működik?

Képzeljük el egy bejelentkezési formot, ahol a felhasználónév és jelszó alapján ellenőriznek egy XML dokumentumban:

//users/user[username='<input_username>' and password='<input_password>']

Ha a támadó a felhasználónév mezőbe ' or '1'='1, a jelszó mezőbe pedig ' or '1'='1 értéket adja meg, a lekérdezés így módosul:

//users/user[username='' or '1'='1' and password='' or '1'='1']

Ez a lekérdezés mindig igaz lesz, bypassolva a hitelesítést és jogosulatlan hozzáférést biztosítva.

Védekezés XPath Injection ellen:

Paraméterezett XPath lekérdezések: Amennyiben az XML technológia támogatja, használjon paraméterezett lekérdezéseket. Ez elválasztja az adatot a lekérdezési logikától.
Input validáció: Szigorúan validálja és tisztítsa meg az összes felhasználói inputot, mielőtt XPath lekérdezésekben felhasználná. Tiltsa le az olyan speciális karaktereket, mint az aposztróf (‘), idézőjel („), egyenlőségjel (=), logikai operátorok (OR, AND).
Legkevesebb jogosultság elve: Csak a feltétlenül szükséges információt adja vissza az XPath lekérdezésekkel. Ne fedjen fel érzékeny adatokat, még akkor sem, ha a támadó manipulálni tudta a lekérdezést.

4. XSLT Injection

Az XSLT (Extensible Stylesheet Language Transformations) egy XML alapú nyelv, amelyet XML dokumentumok transzformálására használnak más formátumokba (pl. HTML, PDF, más XML). Az XSLT injection akkor fordulhat elő, ha egy alkalmazás felhasználói inputot fogad el XSLT stíluslapként, vagy annak részeként, és azt szerveroldalon hajtja végre.

Hogyan működik?

Sok XSLT processzor képes script nyelvek (pl. JavaScript, Python) kódját beágyazni és végrehajtani a transzformáció során. Ha a támadó kontrollálja az XSLT stíluslapot, vagy annak egy részét, rosszindulatú kódot injektálhat, ami a szerveren fog futni.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:java="http://xml.apache.org/xslt/java" exclude-result-prefixes="java">
  <xsl:template match="/">
    <xsl:value-of select="java:lang.Runtime.getRuntime().exec('id')"/>
  </xsl:template>
</xsl:stylesheet>

Ez a példa, megfelelő környezetben, futtatja az id parancsot a szerveren, és megjeleníti annak kimenetét. Ez távoli kódvégrehajtáshoz (RCE) vezethet.

Védekezés XSLT Injection ellen:

Felhasználói XSLT bevitel tiltása: Soha ne engedje meg a felhasználóknak, hogy XSLT stíluslapokat töltsenek fel, vagy azok részleteit manipulálják.
Scripting letiltása: Tiltsa le az XSLT processzorban a script nyelvek futtatását. A legtöbb XSLT processzor (pl. Saxon, Apache Xalan) biztosít erre konfigurációs opciókat.
Erőforrás-hozzáférés korlátozása: Korlátozza az XSLT processzor számára elérhető erőforrásokat és a hálózati hozzáférést (sandbox környezet).

5. XML DoS (Szolgáltatásmegtagadás) nagyméretű fájlokkal

A már említett XML Bomb mellett, egyszerűen egy nagyméretű XML fájl feltöltése is okozhat szolgáltatásmegtagadást, ha a szerver nem képes hatékonyan kezelni azokat. A parser megpróbálhatja az egész dokumentumot memóriába tölteni, ami erőforrás-kimerüléshez és az alkalmazás összeomlásához vezet.

Védekezés DoS nagyméretű fájlokkal szemben:

Input méretkorlátozás: Állítson be maximális méretet a HTTP kérések (és az XML tartalom) számára a web szerveren vagy az alkalmazás szintjén.
Stream alapú feldolgozás: Használjon SAX vagy StAX parsereket a DOM (Document Object Model) alapú parserek helyett, ha lehetséges. A DOM parserek az egész dokumentumot betöltik a memóriába, ami nem skálázódik jól nagy fájlok esetén.
Timeout-ok konfigurálása: Állítson be timeout-okat a parser számára, hogy megakadályozza a túl hosszú ideig tartó feldolgozást.

6. Schema Validáció megkerülése

Az XML sémák (DTD, XML Schema) célja az XML dokumentumok struktúrájának és adattípusainak validálása. Ha azonban a támadó képes manipulálni a sémát, vagy olyan XML-t küld, amely nem felel meg a várt sémának, de a rendszer mégis feldolgozza, az biztonsági rést okozhat.

Hogyan működik?

Egy rosszindulatú felhasználó olyan XML-t küldhet, amely strukturálisan érvényes a rendszer számára, de tartalma ellentmond a várt üzleti logikának, vagy kihasználja a későbbi feldolgozási szakaszokban lévő hibákat. Például, ha egy rendszer egy XML sémára támaszkodva ellenőriz jogosultságokat, és a támadó egy módosított sémát vagy nem validált XML-t küld, az jogosultság emeléshez vezethet.

Védekezés Schema Validáció megkerülése ellen:

Mindig megbízható sémákat használjon: Ne engedje, hogy a felhasználó határozza meg vagy manipulálja a használt sémát. A sémáknak a szerveren kell lenniük, és nem szabad kívülről betölteni őket.
Szigorú validáció: Gondoskodjon arról, hogy az XML dokumentumok szigorúan validálva legyenek a sémával szemben, még mielőtt a feldolgozás megkezdődne.
„Defense in Depth”: A séma validáció csak egy rétege a védelemnek. Ezen felül is szükséges az input validáció és a jogosultság ellenőrzés az üzleti logika szintjén.

Általános Védekezési Stratégiák

A fent említett specifikus sebezhetőségeken túl, van néhány általános jó gyakorlat, amelyet érdemes betartani az XML feldolgozás biztonságának növelése érdekében:

Input Validáció: Ez az egyik legfontosabb védekezési vonal. Minden bejövő XML adatot alaposan validálni és tisztítani kell. Ne bízzon semmilyen felhasználói inputban. Ellenőrizze a méretet, a struktúrát, a tartalom típusát és az értékek tartományát.
Biztonságos Parserek Használata és Konfigurálása: Használjon modern, naprakész XML parsereket. Minden parsernek van egy alapértelmezett konfigurációja, amely gyakran nem optimális a biztonság szempontjából. Kifejezetten tiltsa le a nem szükséges funkciókat, mint például a DTD feldolgozást, külső entitásokat, XInclude-ot, vagy a script futtatást.
Legkevesebb Jogosultság Elve: Az alkalmazásnak és az XML parsernek is csak a minimálisan szükséges jogosultságokkal kell rendelkeznie a feladatai elvégzéséhez.
Hibaüzenetek Kezelése: Ne fedjen fel részletes hibaüzeneteket a felhasználó felé, amelyek információkat tartalmazhatnak a rendszer belső felépítéséről vagy sérülékenységeiről. Logolja a hibákat belsőleg.
Frissítések: Rendszeresen frissítse az XML feldolgozásra használt könyvtárakat és keretrendszereket. A gyártók gyakran adnak ki biztonsági javításokat az újonnan felfedezett sebezhetőségekre.
Tesztelés: Végezzen rendszeres biztonsági tesztelést (pl. penetrációs tesztelés, statikus és dinamikus kódanalízis) az alkalmazásokon, amelyek XML feldolgozást használnak.

Összefoglalás

Az XML továbbra is kulcsszerepet játszik az modern alkalmazásokban, és éppen ezért elengedhetetlen, hogy tisztában legyünk az általa hordozott biztonsági kockázatokkal. Az XXE injection, az XML Bomb, az XPath injection és az XSLT injection csak néhány példa a számos lehetséges támadási vektor közül. A proaktív megközelítés, a biztonságos kódolási gyakorlatok betartása, a parserek helyes konfigurálása és az alapos validáció azonban jelentősen csökkentheti a támadások sikerességének esélyét.

A fejlesztőknek és a biztonsági szakembereknek egyaránt folyamatosan képezniük kell magukat ezen a területen, és integrálniuk kell a biztonságot az alkalmazások tervezésébe és fejlesztésébe a kezdetektől fogva. Ne feledjük: a biztonság sosem egy utólagos gondolat, hanem egy alapvető szempont, amely garantálja rendszereink megbízható és zavartalan működését.