'Onderschat veiligheidsproblemen bij XML niet'

Nu XML steeds meer gebruikt wordt door bedrijven om hun informatie te delen, waarschuwen analisten dat het bedrijfsleven zich nog niet genoeg bewust is van de gevaren van de opmaaktaal. Veiligheidsanalist John Pescatore denkt dat XML een aantal nieuwe veiligheidrisico's met zich meebrengt, maar dat ook een aantal oudere gevaren voor last kunnen zorgen. Op ZDNet lezen we dat de risico's van het XML-gebruik op dit moment beperkt zijn, omdat de webservices die gebruik maken van de extensive markup language vaak enkel te gebruiken zijn door medewerkers van het bedrijf zelf en door vertrouwde derde partijen. Zo gauw het XML echter meer gebruikt gaat worden tegenover de onbekende klant, is het van belang zeker te weten dat de boel erachter goed beveiligd is.

De gevaren stoppen namelijk niet bij het simpelweg platleggen van een website, maar via het bedrijfsnetwerk en de gebruikte applicaties met XML kan een kwaadwillende zijn handen leggen op gevoelige bedrijfsinformatie. Beveiliging tegen XML-aanvallen zijn moeilijk, mede doordat XML-berichten verpakt zijn in een IP-pakketje dat door de firewall wel wordt gescand maar waarbij niet bewust naar de inhoud van het pakketje wordt gekeken. Ook is het mogelijk om met XML een DDoS-aanval uit te voeren, waardoor een wellicht belangrijke netwerkserver op z'n gat gaat. Op dit moment zijn hackers nog niet zo bezig met het aanvallen van XML-doelen, onder andere doordat deze nog vrij weinig gebruikt worden.

Bovendien is voor het hacken van XML-targets veel kennis nodig, waardoor de gemiddelde scriptkiddy niets kan beginnen en de schade vooral wordt veroorzaakt door professionele getrainde hackers. Analisten waarschuwen bedrijven nu dat ze moeten uitkijken naar gespecialiseerde XML-beveiligingsproducten en hun kennis over veiligheidsissues moeten verhogen. Men verwacht dat door stabielere en duidelijkere standaarden voor webservices de boel ook beter en makkelijker te beveiligen zal zijn.

Reacties (40)

[traviandus]

XML is toch niets meer als een standaard manier om informatie door te geven. Als er vervolgens veiligheidsrisico's zijn, dan ligt dat toch aan de applicatie die die informatie interpreteerd en niet aan XML

[RM-rf]

XML is niet enkel een statische taal, maar in zichzelf al een applicatie, die bepaalde standaard gedragingen van een document documenteerd:

de op security focus beschreven aanval betreft een External Entity Attack:
http://www.securityfocus.com/archive/1/297714

het betreft het includen van een <!ENTITY name SYSTEM "URI"> in de DTD.
op de plek van URI kan een verwijzing staan naar een lokaal programma op de server dat hier ge-initieerd kan worden, en dan uitgevoerd wordt met lokale berechtiging.

Een belangrijke tegenmethode moet zijn dat serverbeheerders ook goed zicht houden op welke parsing toegestaan wordt per service, of external entities worden meegeparsed of per applicatie worden beperkt.
Juist die extra belasting op de serverbeheerder, qua zicht op welke toestemmingen parsers hebben is het gevaar.

[Plekuz]

DTD is geen XML, het is zelfs geen XML variant, maar de "ouderwetse" SGML manier om data te beschrijven.

De DTD interpreter zorgt ervoor dat er een veiligheidslek kan ontstaan door dit soort URI ongein, maar dat heeft niets met XML te maken.

XML heeft niet in zichzelf al een applicatie. Dat veel mensen DTD (ipv XSD, wat wel een XML variant is) gebruiken om een XML document te valideren staat daar helemaal buiten.

[riddles]

Inderdaad... In het artikel staat gewoon dat als je data accepteert van "untrusted parties", dat dat gevaarlijk is. Het is mij niet duidelijk wat XML daarmee te maken heeft (in vergelijking met het uitwisselen van text, csv, html, edi bestanden of zelfs e-mail).

[glashio]

Wat is "gevaarlijk" ??

<XML>
<ACTION>explode<ACTION>
<TARGET>bomb</TARGET>
<LOCATION>random</LOCATION>
</XML>

dit sturen naar "xml.al-qaeda.org" ?

[justice strike]

nieuwe headline:

"TXT bestanden mogelijke bron van veiligheidsproblemen"

ja duh, zo kan ik er nog wel een paar

[Verwijderd]

zoiets als: "Computers vaak mogelijke bron van veiligheidsproblemen"?

[RetepV]

Nog effe on-topic:

Bovendien is voor het hacken van XML-targets veel kennis nodig, waardoor de gemiddelde scriptkiddy niets kan beginnen en de schade vooral wordt veroorzaakt door professionele getrainde hackers.

Wat een megadomme opmerking zeg, en dat nog wel van professionele analisten! Zelfs die hebben geen kennis meer.

Wat is een scriptkiddie? Een jochie die ergens een script download waarmee hij met één druk op de knop misbruik kan maken van een vulnerability. Waar haalt dat jochie dat script vandaan? Van een plek waar het door een professionele of in ieder geval gevorderde hacker is neergezet. Moet een scriptkiddie dan kennis hebben van de hack die hij inzet? Nee hoor, hij moet alleen weten waar het te vinden is en moet weten hoe hij met de muis een button indrukt. Kan een gemiddelde scriptkiddie dus gebruik maken van een geavanceerde hack om een server te kraken? JA NATUURLIJK!

De scriptkiddie is niet de hacker, maar hij kan echt wel een software tooltje gebruiken...

Ah, maar ik zie in het originele bericht dat Chris Darby het heeft gezegd en die is CEO van de 'XML network company Sarvega'. Die maakt zich dus schuldig aan belangenverstrengeling. In het originele bericht zegt hij dat de scriptkiddies zich NU nog niet bezighouden met het hacken van XML services. Nee, natuurlijk niet! Want die scriptkiddies hebben nog geen scripts tot hun beschikking. De 'professionele' hackers zijn op dit moment natuurlijk wel bezig om die scripts te maken.

Darby doet het voorkomen alsof er nog niets aan de hand is, simpelweg omdat hij zijn sales niet wil zien inzakken.

XML data is niet anders dan andere data, het is alleen een beetje leesbaarder voor gewone mensen. Ja, er zitten wel meer voordelen aan, maar die doen niet ter zake bij wat ik hier schreef .

[QuarkuS]

Wat een megadomme opmerking zeg, en dat nog wel van professionele analisten! Zelfs die hebben geen kennis meer.

Wat een megaslechte troll zeg, en je krijgt er nog wel +4 inzichtvol voor.

Anders lees je dus even wat er gezegd wordt:

"Your average script kiddie in a black T-shirt in his basement is probably not hacking XML yet. You need to get a computer science degree to do that," said Chris Darby, chief executive of XML network company Sarvega and former CEO of security company @stake. "So, if there are attacks, they aren't very sophisticated."

Hij zegt dus effectief dat scriptkiddies geen aanvallen kunnen bedenken, en omdat er nog niet zoveel aanvallen bekend zijn, heb je dus nog geen last van scriptkiddies.

En dan komt er nog een mooie troll over belangenverstrengeling achteraan. Lekker bezig he?
[/offtopic]

En dan nog even wat relevants: zoals dit nieuwsartikel geschreven is, verdraait het behoorlijk wat er in het originele artikel stond, en ziet het er aanzienlijk voordehandliggender uit. Het kan dus niet echt kwalijk genomen worden als mensen domme dingen gaan zeggen n.a.v. dit nieuwsbericht. Maar zoals bij de meeste artikelen loont het de moeite om het originele even te lezen. Zo ook hier:

Beveiliging tegen XML-aanvallen zijn moeilijk, mede doordat XML-berichten verpakt zijn in een IP-pakketje dat door de firewall wel wordt gescand maar waarbij niet bewust naar de inhoud van het pakketje wordt gekeken.

Ze pleiten dus eigenlijk gewoon voor een application level firewall. Heeft ook niks met IP te maken, maar met het applicatie protocol wat erin zit. En volgens mij is dat de kern van hun hele verhaal.

Ook is het mogelijk om met XML een DDoS-aanval uit te voeren, waardoor een wellicht belangrijke netwerkserver op z'n gat gaat.

versus:

The equivalent [of a DDoS, red] in XML applications is an XML denial-of-service attack, when a spike in incoming XML messages, which could be bogus, takes a network server out of commission. Malicious hackers also could manipulate the contents of XML documents to bog down a system, Heffner noted.

En het doel van een DDoS aanval is inderdaad meestal dat er een netwerkserver op z'n gat gaat, beter nog: een netwerkserver die wellicht belangrijk is.

[Verwijderd]

Volgens moet je niet naar XML kijken, daar is niets mis mee. Wat intersant is zijn de protocollen waarover wordt gecomminceerd. Die zijn goed te beveiligen, alleen de mensen die de software maken moet dat wel even doen. Dat kost tijd en geld dus denken ze dat het ook wel even zonder kan. SOAP het protocol waarover B2B of B2C XML moeten dan ook werkelijk gebruikt worden om over netwerken te comuniceren. Om dit te implementeren heb je iets meer kennis nodig dan gewoon de XML spec, een goede analyse van het hele systeem is dan belangrijke (hoe communiceer je keys en welke encrypties gebruik je waar).

[joho]

He is niet XML maar juist SOAP (over HTTP) welke het gevaar oplevert. SOAP is erg in opkomst en word als de standaard gezien, toch betekend dit niet dat SOAP een 'goede' standaard is. (Het bekende VHS video tape verhaal.)
SOAP glijdt, met HTTP als glijmiddel, makkelijk door firewalls heen. Om dit nog enigzins te beveiligen zouden firewalls ook naar de inhoud van het HTTP berichten verkeer moeten kijken, maar dat is slechts een workaround.

[coubertin119]

XML is een taal waarmee gegevens tussen applicaties uitgewisseld kunnen worden. Zulke gegevens moeten ook àltijd beveiligd worden. Zelfs al is het met .txt'tjes.

XHTML, MathML, SVG zijn allemaal op XML gebaseerde standaarden. Zijn ze daarom allemaal gevaarlijk?

[PolarWolf]

Typisch een voorbeeld van "shoot the messenger" (XML dus).
Sorry hoor, maar XML is echt een communicatievehikel. Dat de zenders en ontvangers vervolgens de verkeerde dingen gaan doen op basis van het bericht kun je moeilijk het formaat zelf aansmeren. Lekker makkelijk om de XML standaard de schuld te geven van slechte implementaties. Bovendien, ik heb ook nog nooit iemand zien klagen over SGML of HTML, die in dezelfde familie zitten als XML. Waarom nu ineens over XML wel? Nou, omdat de afkorting een hoog marketing gehalte heeft, daarom. Lekker productjes verkopen die zogenaamd XML beveiligen, terwijl alles wat je nodig hebt een fatsoenlijke validatie van input (misschien moeten die dure programmeurs eens een schop onder hun luie r33t krijgen) en een veilig communicatiekanaal is. Een non-issue, zoals zovele non-issues die door CEOs van toevallig in hetzelfde vakgebied werkzame non-bedrijfjes regelmatig weer eens aangezwengeld worden.

[Verwijderd]

Tsja, neem Internet Explorer, het meest brakke stuk software ooit door microsoft geschreven, dat heeft ook elke paar week wel een nieuw lek waardoor cross-scripting of zelfs remote code execution mogelijk is met gewoon HTML.

Is HTML nu ook 'onveilig'? Of is het gewoon het programma dat onveilig is, en is HTML *als protocol* gewoon veilig omdat er ook veilige implementaties van zijn?

Een nogal onduidelijke redenering hebben die zogenaamde analisten. Als de top beveiligings analisten zo zijn vraag ik me niet meer af waarom het internet onveilig is :-)

[Herko_ter_Horst]

Vervang in het artikel "XML" door "ASCII" en het wordt duidelijk hoe ver de plank hier wordt misgeslagen.

[TukkerTweaker]

Dat ben ik niet met je eens, een ASCII bestand kan geintrepeteerd worden door een server maar de hacker kan nooit weten welke waarden de onderliggende applicatie toepast.
Bij XML loert het gevaar vooral in openbare dtd's of schema's.

[kalizec]

Als je je gegevens in XML ook van zinloze naamgeving voorziet is het voor een hacker echt niet makkelijker om XML te interpreteren dan ASCII of zo.

XML is niets anders dan een standaard om gegevens in op te slaan.

Als het nou een protocol zou gaan, dan had je het inderdaad zinnig over veiligheid kunnen hebben, maar de enige zinnige boodschap van dit artikel is: "Huidige implementaties van XML vaak onveilig." Of zoiets. Wellicht dat dit ook iets meer in het dit news-item naar voren gehaald kan worden?

[Verwijderd]

Als je je gegevens in XML gaat voorzien van zinloze naamgeving, waarom dan nog XML gebruiken? Want bij de naamgeving stopt het niet: de waarden zelf kunnen immers ook nog geïnterpreteerd worden. Met andere worden: jij geeft hier een argument om gebruik te maken van binaire dataformaten, omdat die eerst gedecodeerd moeten worden (en ten opzichte van human-readable garbage XML toch echt alleen voordelen bieden).

Wat hier gewoon moet gebeuren is dat men zich niet zo richt op de berichten zelf (want ieder human-readable berichtenformaat is kwetsbaar), maar de beveiliging van (1) het communicatiekanaal, (2) de applicatie en (3) de host. Die berichten zijn immers in mum van tijd te encrypten zodat een eavesdropper er al niets meer mee kan. Waar het nu nog aan schort zijn goede beveiligingsmethoden voor Web Services (WS-Security ziet er veelbelovend uit). Daarbij zijn de nu actieve Web Services van een dermate "trial"-kwaliteit dat er nauwelijks aandacht is besteedt aan STRIDE en dus beveiliging van applicatie en host.

[Verwijderd]

Uhh...

XML berichten kan je toch evengoed coderen? Desnoods base64-encode en wrap je het in <ENCRYPTEDTEXT> oid en je hebt weer XML

<ENCRYPTED METHOD="idea" KEYSIZE=10240 ARMOR="base64">
19239329988298321998332985954985439853543
5435435435435454343435435435435435435435435
43543543543543543543543543543543543543543543
4334354354354543543543543543543554543543543
</ENCRYPTED>

Leg mij maar es uit waarom dit onveiliger is dan een binary formaat .. (let wel, bij binary formaten kan je vaak met een hex editor gewoon de teksten binnenin lezen, en veel binary formaten zoals Word/Excel/etc.. hebben een manier om uitvoerbare macro's erin te zetten)
Je hebt hier encryptie verwar dit niet met obfuscatie wat binary formaten doen en geen enkele extra veiligheid oplevert..

[Herko_ter_Horst]

Beveiligingslekken door het op de een of andere manier interpreteren van gegevens gelden altijd. Je zult voor alle gegevens die je binnenhaalt of uitstuurt moeten kijken naar beveiliging (authenticatie, authorisatie, integriteit).

XML is wat dat betreft niet gevaarlijker dan ASCII, integendeel: juist omdat er gedefinieerd is hoe je XML moet lezen (en wat er dan gebeurd) ben je veel minder afhankelijk van de luimen van een specifieke applicatie die ongedefinieerde betekenis kan toekennen aan een willekeurige reeks ASCII-tekens.

[miw]

Elke .BAT file is dus onschuldig want het bevat alleen maar ASCII teken?. Met een simpel script kan je heus veel schade aanrichten.

[Verwijderd]

Was w3.org niet bezig met secure XML te definieeren of zijn ze daar al weer klaar mee?
Kan ook in de war zijn met compressed XML.

Maar als je https kan gebruiken voor HTML kan je ook XMLs gebruiken voor secure XML.

Ik snap het 'probleem' dan ook niet zo. Het zit eerder in het feit of men XML toepassingen niet zomaar met open poorten aan het internet hangt. (ala IIS)

[Verwijderd]

Met gesloten poorten aan het internet is namelijk veel handiger ?

Overigens wordt er in het stukje hierboven een ontzettende berg poep gepraat, het probleem zit hem niet zozeer in de xml (eXtensible Markup Language), maar in de manier waarop applicaties data valideren, die van buiten komt, gebruikers zijn in principe te dom om te poepen en maken gegarandeerd de meest domme fouten ( "Is ZZ dan geen cijfer?" ).

Het maakt verder niet uit of de server met SSL beveiligt is of niet, dat voorkomt alleen dat de data niet door een 3de kan worden verandert.

[papmetklonten]

waarom word er tegenwoordig zo weinig op veiligheid gelegd. We geven tegenwoordig steeds meer prijs op de computer. Maar de gemiddelde scriptkiddie kan overal inkomen. Ik wou dat er eens wat gedaan werd aan de beveiliging ipv steeds nieuwe produten op de markt te brengen.

[Ximinez]

Niet alleen tegenwoordig. Alleen door aandacht in de media en het toegenomen computer gebruik hebben het onder aandacht gebracht van het grote publiek.

Maar het probleem is niet zozeer een technische als wel een sociale. Ten eerste is er de wil om in te breken, waar vroeger kleine jongetjes een vuurtje gingen stoken gebruiken ze nu de computer. Maar vooral belangrijk is het ontbreken van de wil tot het beveiligen van gegevens een belangrijke factor. Mensen die nonchalant omgaan met bijv. hun portefeuille of autosleutels zullen achter de computer ook niet zorgvuldig omspringen met zaken die van waarde zijn.

Dat gedrag verander je niet door het beschikbaar stellen van beveiligingsproducten voor de computer in het algemeen. Ik ken genoeg mensen in mijn omgeving die geen wachtwoord op de computer instellen omdat zij dat lastig vinden. Ja dan kan je net zo goed je huissleutel in het slot laten zitten en dan wel aan de buitenzijde van de deur.

Het is een fact of live en daaraan zal weinig tot geen verandering in optreden.

Elke vorm van informatie uitwisseling op welk abstract niveau dan ook zal altijd veiligheidsrisico's met zich meebrengen. De vraag rijst wat acceptabel is en wat niet.

[RetepV]

Ik denk dat je ook eerlijk moet zijn en toe moet geven dat het voor veel mensen allemaal een beetje te snel gaat. Het gaat namelijk niet alleen om services bij bedrijven, maar ook bij de mensen thuis. XML parsing wordt door Microsoft tegenwoordig overal in gestopt.

De mensen thuis willen hun computer gewoon gebruiken, dus die kijken misschien ééns in de maand of er een update is (als ze al weten dat dat kan). Terwijl er minstens 3 security vulnerabilities per maand worden gemeld.

Als je software aan gewone mensen gaat verkopen moet je niet alleen aan je eigen portemonnaie denken, maar ook aan het feit dat voor die mensen hun computer niet het centrum van hun leven is. Dat vergeten ze bij Microsoft regelmatig, en ook bedrijven die client- en serverapplicaties maken denken daar vaak niet goed over na.

Hardstikke fout, natuurlijk, maar er is niemand die die bedrijven op hun vingers tikt.

[Squee]

Op dit moment zijn hackers nog niet zo bezig met het aanvallen van XML-doelen, onder andere doordat deze nog vrij weinig gebruikt worden.
Bovendien is voor het hacken van XML-targets veel kennis nodig, waardoor de gemiddelde scriptkiddy niets kan beginnen en de schade vooral wordt veroorzaakt door professionele getrainde hackers.

Dit vind ik wel een beetje een erg raar argument... het zal me niets verbazen als zo'n "professioneel getrainde hacker" binnenkort een tooltje schrijft voor een leuke XML hack waardoor de skriptkiddies alsnog volop "plezier" er aan kunnen beleven...

* 786562 Squee

[n4m3l355]

dit soort tools worden veel gepubliceerd dus misschien dat het toch wel wat complexer is dan dat het lijkt anders waren deze al langer makkelijk te vinden.
waarschijnlijk omdat je rekening moet houden met de verschillende vertexen en variabelen in de onderlinge velden en scripts die erin opgemaakt zijn.

[RetepV]

Het ontwikkelen van de atoombom was ook heel wat complexer dan het leek. Toch heeft iemand het voor elkaar gekregen en toen dat eenmaal zo ver was kon ineens iedereen het.

Iemand met verstand van zaken hacked de boel en vervolgens kan elke slome duikelaar ook hacken omdat hij alleen maar precies na hoeft te doen wat die hacker deed.

Een 'professionele' hacker zal geen XML targets aanvallen als hij er niets mee bereikt.

Kom op zeg, hackers worden niet anders gemotiveerd dan andere mensen. De meeste doen het voor de eer, een aantal voor het geld. Er is niemand die het doet omdat hij er toevallig zin in had. Een motief is er altijd.

[Verwijderd]

Zijn er uberhaupt opleidingen om 'hacker' te worden dan? Ik weet wel dat er bij informatie af en toe aandacht aan black/white hat hacking gegeven wordt maar om dat een hackers opleiding te noemen lijkt me iets overtrokken.

[RetepV]

Ik heb geen idee, maar als je bij een grote terroristenorganisatie aanklopt en zegt dat je hacker voor hen wil worden zullen ze je vast wel naar een kenniscentrum doorsturen en daar zullen ze je alles bijbrengen wat ze weten. En dat is dus de definitie van een opleiding.

Als je bij die andere terroristenorganisatie aanklopt, de CIA, dan zullen ze waarschijnlijk wel hetzelfde doen.

[Tha Man]

Wat volgens mij ook nog speelt, jammer genoeg, is dat als Microsoft XML als haar eigen standaard gaat zien, er veel mensen zullen zijn die deze standaard onderuit proberen te halen. Dat slaat natuurlijk als een tang op een varken, maar dat zie je wel meer, zoals bij alle grote beveiligingslekken van microsoft. Ook toen Hotmail net was overgenomen door microsoft waren er ineens veel lekker snel gevonden terwijl die daarvoor natuurlijk ook allang aanwezig waren.

Ik denk dus dat het in ieder z'n belang is om XML goed te leren beveiligen, zodat niet een bedrijf hier schuldig aan wordt bevonden, al of niet dat ergens op slaat (dat laat ik wijzelijk in het midden )