Fingerprinting of XML Libraries through Storage Side Channel

Transcription

Fingerprinting von XML-Bibliotheken durch
Storage-Seitenkanäle
—
Fingerprinting of XML Libraries through
Storage Side Channels
Bachelorarbeit
von
Thilo Mothes
1. Juni 2011
Vorgelegt am Lehrstuhl für Praktische Informatik I
Laboratory for Dependable Distributed Systems
Universität Mannheim
Gutachter: Prof. Dr. Felix Freiling
Betreuer: Sebastian Schinzel
II
Eidesstattliche Erklärung
Ich versichere, dass ich meine Bachelorarbeit ohne Hilfe Dritter und ohne Benutzung
anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten
Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.
Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Hirschhorn, den 1. Juni 2011
Unterzeichner
III
Inhaltsverzeichnis
Abbildungsverzeichnis
VI
Verzeichnis der Quellcodes
VII
1. Einführung
1.1. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Ausblick auf die Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen
2.1. Seitenkanäle . . . . . . . . . . . . . . . . . . . .
2.1.1. Fingerprinting . . . . . . . . . . . . . . .
2.2. XML und zusammenhängende Konzepte . . . .
2.2.1. Extensible Markup Language . . . . . .
2.2.2. Welche Probleme löst XML? . . . . . . .
2.2.3. XML-Dokumente . . . . . . . . . . . . .
2.2.3.1. Wohlgeformtheit . . . . . . . .
2.2.3.2. Validität . . . . . . . . . . . . .
2.3. XML-Bibliotheken . . . . . . . . . . . . . . . .
2.3.1. Apache Xerces Java (Xerces) . . . . . . .
2.3.2. Microsoft XML Core Services (MSXML)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
3
4
4
5
5
5
6
6
9
10
11
13
13
3. Vorgehensweise
15
3.1. Strukturelle Unterschiede . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Formatierung und Prettyprint . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Verwendete Suchmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Durchführung
20
4.1. Benutztes System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Nutzung einer XML-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . 20
5. Untersuchung
23
5.1. Xerces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Xerces-J 1.4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.2. Xerces2-J 2.11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
IV
Inhaltsverzeichnis
5.2. MSXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. MSXML3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2. MSXML6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Evaluation
6.1. Xerces . . . . . . . . . . . . . . . .
6.2. MSXML . . . . . . . . . . . . . . .
6.3. Die XML-Bibliotheken im Vergleich
6.4. Suchmuster für Angreifer . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
31
31
32
32
33
7. Abschluss
35
7.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2. Ergebnisse & Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3. Beschränkungen & Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . 36
Literaturverzeichnis
37
A. Anhang
41
V
Abbildungsverzeichnis
2.1. XML-Hierarchie (Beispiel) . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Aufbau einer XML-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . .
8
12
4.1. Einbinden der Xerces-Bibliothek . . . . . . . . . . . . . . . . . . . . . . .
21
5.1.
5.2.
5.3.
5.4.
26
27
28
28
Xerces 1.4.4 Hex-Editor-Ansicht (Zeilenumbruch markiert) . .
Vorher/Nachher - Vergleich des CDATA-Blocks . . . . . . . .
Vorher/Nachher – Vergleich bei Prettyprint . . . . . . . . . .
Xerces 2.11.0 Hex-Editor-Ansicht II (Zeilenumbruch markiert)
VI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Verzeichnis der Quellcodes
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
Verschachtelungsbeispiel . . . . . . . . . . . . .
Beispiel für leere Tags . . . . . . . . . . . . . .
Beispiel für den Attribut-Gebrauch . . . . . . .
Beispiel einer XML-Deklaration . . . . . . . . .
Beispiel eines Kommentars . . . . . . . . . . . .
XML-Dokument . . . . . . . . . . . . . . . . . .
Beispiel für falschen Attributgebrauch . . . . . .
Beispiel für falsche Verschachtelung . . . . . . .
Beispiel für den Einsatz eines CDATA-Bereichs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
7
7
7
8
9
9
10
3.1.
3.2.
3.3.
3.4.
Beispiel Strukturunterschiede . . .
Beispiel Strukturunterschiede II . .
Prettyprint-Beispiel . . . . . . . . .
Auszug aus dem Originaldokument
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
16
18
5.1.
5.2.
5.3.
5.4.
Auszug der Ausgabedatei nach Xerces 1.4.4 mit Prettyprint .
kurzer Auszug aus dem Originaldokument . . . . . . . . . .
Auszug der Ausgabedatei nach Xerces 1.4.4 ohne Prettyprint
MSXML-Formatierung . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
26
29
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1. Einführung
Bei der Kommunikation zweier Systeme kann es passieren, dass unentdeckt und unerwünscht Informationen übertragen werden. Dies geschieht meistens über Kommunikationswege, die nicht zur Kommunikation gedacht waren. Dieses Phänomen nennt man
Seitenkanal (siehe Abschnitt 2.1). Fingerprinting ist eine Möglichkeit, wie diese Seitenkanäle genutzt werden können. Hierbei handelt es sich um eine Methode, mit der
Hersteller und Version von Software-Anwendungen über ein Netzwerk bestimmt werden
können. Die Zenith Image Gallery ist eine Web-Anwendung, bei der Seitenkanäle existieren. Sie ist damit nicht alleine, dennoch wird nichts dagegen unternommen [8]. Dies
liegt einerseits daran, dass die Betroffenen hiervon nichts wissen oder es einen immensen
Aufwand bedeutet, sie zu unterbinden. Der wichtigste Grund aber ist der, dass die Entwickler und Benutzer dieser Anwendungen sich der Gefahren, die von den Seitenkanälen
ausgehen, nicht bewusst sind.
In dieser Arbeit liegt der Fokus auf XML-Bibliotheken wie Xerces [34]. Diese Bibliotheken stellen Komponenten zur Verarbeitung von XML-Dokumenten bereit. Sie lesen
XML-Dokumente mit Hilfe eines XML-Parsers ein. Anschließend werden die gewonnenen Daten umgewandelt und verarbeitet. Die bearbeiteten Daten können dann in Form
von Nachrichten an andere Anwendungen oder Services weitergeben werden.
XML-Nachrichten werden beispielsweise bei der Kommunikation mit Web-Services benutzt. Ein Web-Service ist hierbei eine Software, die eine genau bestimmte Leistung erbringt. Er verfügt über eine Schnittstelle, über die ein Client oder ein anderer Service mit
ihm via XML-Nachrichten kommunizieren kann. Auf Anfragen liefert der Web-Service
in der Regel Informationen zurück.
Ein Web-Service bekommt beispielsweise von einer Web-Anwendung, die der User
mit seinem Browser aufgerufen hat, eine Anfrage zugesandt. Diese Anfragen werden in
Form von XML-Nachrichten übermittelt. Der Web-Service bearbeitet die Anfrage und
liefert die gewünschten Informationen zurück. Ein Angreifer kann auf verschiedene Art
und Weise in den Prozess eingreifen. Er könnte Antwort-Nachrichten des Web-Service
abfangen, von der Web-Anwendung gesendete Nachrichten manipulieren. Es ist aber
auch möglich, Schadcode, basierend auf dem Wissen, welche XML-Bibliothek in der
jeweiligen Version vorliegt, zu übermitteln. [27]
Hierbei hilft dem Angreifer das bereits erwähnte Fingerprinting. Wenn ein Angreifer
eine dieser Sicherheitslücken für eine spezielle Version einer XML-Bibliothek kennt, so
kann er versuchen mit Hilfe des Fingerprinting ein geeignetes Opfer zu finden.
1
1. Einführung
1.1. Zielsetzung
Ziel dieser Bachelorarbeit war es herauszufinden, ob im Bereich der XML-Bibliotheken
Seitenkanäle existieren, beziehungsweise ob es mit Hilfe der XML-Nachrichten der jeweiligen XML-Bibliothek möglich ist, auf ihren Hersteller und ihre Version zu schließen.
Im Mittelpunkt stand hierbei das Herausarbeiten entsprechender Erkennungsmerkmale.
Hierzu sollten zunächst die unterschiedlichen XML-Bibliotheken konkret implementiert werden. Mit Hilfe dieser Implementationen sollten im Anschluss XML-Dokumente
eingelesen werden. Diese XML-Dokumente galt es in einen DOM-Tree zu wandeln und
anschließend in eine Ausgabedatei zu schreiben. Die resultierenden Ausgabedokumente
sollten dann auf Unterschiede im Ausgabeformat untersucht werden. Es sollte speziell auf
die Umsetzung von Prettyprint geachtet werden, da hier die auffälligsten Unterschiede
vermutet wurden.
Sollte dies möglich sein, so würde dies ein Sicherheitsrisiko bedeuten. Durch das Untersuchen der XML-Nachrichten könnte ein Angreifer auf die auf dem Server liegende
XML-Bibliothek schließen und bekannte Sicherheitslücken dieser Version ausnutzen, sofern vorhanden.
Beispielsweise könnte der Angreifer im schlimmsten Fall beliebigen Schadcode auf
dem System ausführen, wenn er einen Web-Service ausfindig machen würde, der mit
einer nicht aktualisierten Version von MSXML3.0 arbeitet. [31]
Im Umkehrschluss könnte diese Arbeit die Grundlage für die Entwickler zukünftiger
Versionen der Bibliotheken bieten, um Seitenkanäle zu unterbinden.
1.2. Verwandte Arbeiten
Es gab in der Vergangenheit bereits einige Arbeiten zum Thema Fingerprinting. So hat
beispielsweise Andrew Hintz ein Paper darüber geschrieben, wie man Webseiten anhand
ihres Traffics fingerprinten kann [12]. Es handelt sich zwar hierbei auch um eine Arbeit
mit dem Thema Fingerprinting, jedoch standen hier andere Testobjekte im Vordergrund.
Im Themenbereich der Seitenkanäle gibt es ein Paper von Felix C. Freiling und Sebastian Schinzel, das im Rahmen der IFIP SEC2011 publiziert wurde [8]. Es behandelt
die Erkennung von Storage-Seitenkanälen in Netzwerkapplikationen. Während bei dieser
Arbeit der Schwerpunkt auf der allgemeinen Erkennung solcher Seitenkanäle liegt, so
ist der Schwerpunkt dieser Bachelorarbeit auf XML-Bibliotheken gerichtet.
Weiterhin existiert eine Dissertation, geschrieben von John O’Donnel, eingereicht an
der University of Dublin, in der XML-basierte Schwachstellen im Xerces-C++ Parser
ausgewertet wurden [27]. Der Schwerpunkt dieser Arbeit liegt bei direkten Angriffen,
wie beispielsweise Denial-of-Service-Attacken. Außerdem wurde die C++ Variante der
XML-Bibliothek Xerces betrachtet.
2
1. Einführung
1.3. Ausblick auf die Arbeit
In Kapitel 2 werden die für das Verständnis notwendigen Grundlagen geliefert. In
Kapitel 3 soll beschrieben werden, wie genau bei der Untersuchung vorgegangen werden
soll. Hier wird erläutert, nach welchen Mustern in den XML-Dokumenten gesucht wird.
Kapitel 4 beschreibt, wie die XML-Bibliotheken konkret implementiert und angewendet werden, sowie alle weiteren Werkzeuge, die für diese Arbeit benutzt wurden.
In Kapitel 5 werden die XML-Dokumente, die die jeweiligen XML-Bibliotheken erstellt
haben, untersucht. Es wurde dabei speziell auf die Muster geachtet, die in Kapitel 3
beschrieben werden. Kapitel 6 präsentiert die Ergebnisse, die aus der Untersuchung
gewonnen werden konnten. Hierbei werden potentielle Angriffsmuster beschrieben.
Im Abschluss werden sowohl die Arbeit, als auch ihre Ergebnisse zusammengefasst.
Zusätzlich wird erklärt, wo die Grenzen der Arbeit liegen und was in Zukunft in dem
Themengebiet der Arbeit noch getan werden könnte.
3
2. Grundlagen
Das folgende Kapitel behandelt die Grundlagen, die für das Verständnis dieser Arbeit
erforderlich sind. Zunächst werden die Begriffe Seitenkanal und Fingerprinting erklärt.
Anschließend wird XML beschrieben, welches der zentrale Begriff dieser Arbeit ist. Als
letztes werden anschließend XML-Bibliotheken beschrieben und zwei konkrete Beispiele,
Xerces und MSXML, genannt.
2.1. Seitenkanäle
Seitenkanäle sind abstrakte Kommunikationswege, die für Seitenkanalangriffe genutzt
werden können. Diese Angriffe unterscheiden sich von direkten Angriffen in der Art
der Kommunikation. Direkte Angriffe, wie Denial-of-Service-Attacken, benutzen direkt
zugängliche Kommunikationswege und nutzen dort gezielt Schwachstellen aus. Im Gegensatz zu Seitenkanalangriffen greifen sie direkt die Ressourcen eines Systems an. Seitenkanalangriffe hingegen nutzen Kommunikationswege, die nicht explizit zur Kommunikation gedacht waren. Diese Seitenkanäle sind in der Regel unsichtbar und ungewollt.
Über sie werden vom Sender unfreiwillig Informationen übertragen, ohne dass er davon
weiß. Aus diesen Informationen können unter Umständen vertrauliche Informationen
oder Systemzustände ermittelt werden. [8]
Seitenkanäle können in zwei Kategorien aufgeteilt werden. Es gibt die sogenannten
Timing-Seitenkanäle, sowie die Storage-Seitenkanäle.
Nutzt man einen Timing-Seitenkanal für Angriffe, so spricht man von einem TimingAngriff. Diese Angriffe zeichnen sich dadurch aus, dass sie Informationen aus den Ladezeiten eines Systems generieren. Die Ladezeiten komplexer Web-Applikationen sind oft
abhängig davon, ob ein Nutzer diese Seite bereits besucht hat oder eingeloggt ist. Es ist
demnach beispielsweise möglich, durch die Messung der Ladezeit des Webseitenaufrufs
darauf zu schließen, ob der Nutzer die Seite vorher schon einmal besucht hat. [29]
Der Fokus dieser Arbeit liegt auf den Storage-Seitenkanälen. Der Unterschied zu
Timing-Seitenkanälen liegt im Medium, welches untersucht wird. Während bei den
Timing-Seitenkanälen der Fokus auf der Messung von Zeitunterschieden liegt, wird bei
Storage-Seitenkanälen der Inhalt der Antworten des Systems untersucht. Eine Antwort
ist der Inhalt, den das System zurückliefert, nachdem es eine Anfrage bearbeitet hat. Bei
der Kommunikation zwischen einem Web-Browser und einem Server kann eine Antwort
beispielsweise eine Webseite oder eine downloadbare Datei sein. In dieser Arbeit wird es
sich um eine XML-Datei handeln, die von einer XML-Bibliothek erzeugt wurde.
4
2. Grundlagen
Die zugrunde liegende Idee ist die, dass verschiedene Antworten der Systeme miteinander verglichen werden, sodass hieraus im Idealfall Informationen generiert werden
können. [8]
2.1.1. Fingerprinting
Fingerprinting ist eine Möglichkeit die bereits beschriebenen Storage-Seitenkanäle zu
benutzen. Hierbei handelt es sich um eine Methode, mit der man Hersteller und Version
von Software-Anwendungen über ein Netzwerk bestimmen kann. Dies gelingt meist auch
dann, wenn diese Informationen nicht explizit von dem System kommuniziert werden. Besondere Popularität in diesem Bereich genießt das sogenannte „OS-Fingerprinting“ [18],
welches weit verbreitet ist. Bei dieser Art des Fingerprinting werden das Betriebssystem
und seine Version anhand des Verhaltens des zugrunde liegenden Systems ermittelt. Mit
diesem Wissen kann ein Angreifer gezielt nach versions- und betriebssystemspezifischen
Sicherheitslücken in dem System suchen. [18][17]
Dies ist auch die dem Fingerprinting von XML-Bibliotheken zugrunde liegende Idee.
Es soll anhand der Nachrichten beziehungsweise Dokumente, die eine XML-Bibliothek
erstellt, erkannt werden, welche Version welcher Bibliothek benutzt wurde. Auch hier ist
es möglich, gezielt Schwachstellen auf dem Fremdsystem auszunutzen.
2.2. XML und zusammenhängende Konzepte
Die Extensible Markup Language, kurz XML, ist der Trend der letzten Jahre. Die
Sprache wurde 1998 zum W3C -Standard [3], doch erst in den letzten Jahren kam der
Boom. XML stellt in dieser Arbeit einen wichtigen Bestandteil dar. Die Bibliotheken,
die auf Fingerprinting untersucht werden sollen, behandeln XML.
2.2.1. Extensible Markup Language
XML ist keine Programmiersprache und kann somit keine komplexe Geschäftslogik
oder Vergleichbares implementieren. Sinn und Zweck von XML ist die Strukturierung
von Daten. Mit Hilfe von Elementen, Attributen und sogenannten Tags werden beispielsweise Konfigurationsdateien, Nachrichten-Feeds oder auch Musikbibliotheken strukturiert. Hierbei erkennt man Parallelen zu HTML, einer Sprache zur Darstellung von
Web-Inhalten, die ebenfalls mit Tags und Attributen arbeitet. Der Hauptunterschied
zwischen HTML und XML ist der, dass XML keine feste Menge an Tags und Attributen
hat. Bei XML ist man weniger eingeschränkt in der Wahl der Tags und Attribute. Weiterhin interpretiert XML selbst keine Daten. Dies übernehmen andere Anwendungen.
[3] [11]
5
2. Grundlagen
Bei XML handelt es sich um eine Metasprache. Metasprachen zeichnen sich dadurch
aus, dass diese Sprachen Untersprachen beschreiben können. Aus dieser Eigenart heraus
hat sich eine Vielzahl von XML-Subsprachen entwickelt, die die verschiedensten Zwecke
erfüllen. So dient XQuery [7] zum Beispiel zum Datenzugriff, wohingegen XHTML [40]
im Bereich der Ausgabe anzusiedeln ist. Es ist auch möglich, verschiedene XML-Formate
miteinander zu kombinieren. [38]
Aktuell existieren zwei verschiedene XML-Standards – XML 1.0 und XML 1.1. Der
grundsätzliche Unterschied liegt darin, dass die beiden die Namensgebung unterschiedlich streng umsetzen. Weiterhin unterscheiden sie sich in der Unicode-Handhabung. Für
nähere Informationen zu den beiden Versionen sei hier auf die Website des W3C verwiesen. [39][19]
2.2.2. Welche Probleme löst XML?
XML ist vielseitig einsetzbar. Sollen komplexe Datenstrukturen wie ein Graph oder
ein Heap [4] über ein Netzwerk versandt werden, so stellt XML eine Lösung für dieses Problem dar. XML ermöglicht es, derartige Datenstrukturen in serialisierter Form
darzustellen. Unter Serialisierung versteht man die Umwandlung eines Objektes in eine
Form, die gespeichert oder transportiert werden kann.
Auch zur Kommunikation kann XML verwendet werden. Es gibt Web-Services, welche beispielsweise das SOAP-Protokoll [13] verwenden um mit anderen Systemen Daten auszutauschen. SOAP ist ein Protokoll, bei dem Sender und Empfänger XMLNachrichten benutzen um miteinander zu kommunizieren. Auf diese Weise gewährleistet
XML system- und plattformunabhängige Kommunikation.
XML ermöglicht es weiterhin, einen Datensatz auf verschiedene Arten zu präsentieren
und zu verarbeiten. Daten werden von XML selbst nicht interpretiert. Jedoch kann es
dafür verwendet werden, um mit nur einer einzigen Quelle mehrere verschiedene Ausgabeformate zu produzieren. Es ist zum Beispiel machbar, aus einer Quelldatei, mit
entsprechenden Hilfsmitteln, einen RSS-Feed und eine PDF-Datei zu generieren. [10]
2.2.3. XML-Dokumente
Die Informationen, die in XML-Dokumenten gespeichert werden, können später von
anderen Anwendungen interpretiert werden. Diese Informationen werden mithilfe von
Tags und Attributen strukturiert. Tags werden durch eckige, spitze Klammern (< und
>) gekennzeichnet. Sie umschließen in der Regel Daten, können aber auch weitere Tags
beinhalten, wie folgendes Beispiel illustriert:
1
2
3
4
5
< tags >
Here is a data string
< tag > another tag </ tag >
< tag > containing data </ tag >
</ tags >
6
2. Grundlagen
Quellcode 2.1: Verschachtelungsbeispiel
Ein Tag muss immer geschlossen werden. Es gibt zwei verschiedene Arten dies durchzuführen. Entweder man schließt das Tag, wie im obigen Beispiel, durch ein End-Tag.
Alternativ fügt man am Ende des Tags einen Slash ein:
1
2
3
4
5
< tags >
< emptyTag / >
< tag > data </ tag >
< tag > values </ tag >
</ tags >
Quellcode 2.2: Beispiel für leere Tags
In diesem Beispiel wurden keine Daten gespeichert. Es handelt sich um ein leeres Tag.
Neben den Informationen zwischen den Tags gibt es auch Informationen innerhalb der
Tags: Attribute. Diese werden direkt in das Start-Tag hineingeschrieben. Ein Tag kann
beliebig viele Attribute enthalten.
1
2
3
4
5
< tags >
< anotherTag number = " 123 " / >
< tag attribute = " value " attribute2 = " text " > data </ tag >
< anotherTag id = " 1 " / >
</ tags >
Quellcode 2.3: Beispiel für den Attribut-Gebrauch
Damit ein XML-Dokument auch als solches erkannt wird, beginnt es mit einer XMLDeklaration. In dieser wird die Versionsnummer der verwendeten XML-Version angegeben. Weiterhin kann auch angegeben werden, mit welchem Zeichensatz das Dokument
kodiert werden soll und ob es sich um eine alleinstehende Datei handelt:
1
<? xml version = " 1.0 " encoding = " UTF -8 " standalone = " yes " ? >
Quellcode 2.4: Beispiel einer XML-Deklaration
Das version-Attribut ist hierbei das einzige Attribut, das zwingend angegeben werden
muss. encoding und standalone sind optional.
Es ist möglich, einzelne Passagen eines XML-Dokumentes zu kommentieren. Hierbei
öffnet man ein Kommentar-Tag mit . Zwischen die
beiden Tags kann der gewünschte Kommentar eingefügt werden, wie in dem folgenden
Beispiel zu sehen ist:
1
2
<! -- this is a comment -- >
< tagsToCome / >
Quellcode 2.5: Beispiel eines Kommentars
Fertiggestellte XML-Dokumente können als Baum interpretiert werden. Ein Baum ist
eine hierarchische Datenstruktur. Sie beginnt mit einem Wurzelelement. Dieses Wurzelelement kann sogenannte Kindknoten in Form von Tags besitzen. Diese können wiederum
7
2. Grundlagen
Kindknoten besitzen. Die Daten der Tags werden in der Baumstruktur als Blätter dargestellt. In Kapitel 2.3 gibt es weitere Informationen hierzu. [4]
In Abbildung 2.1 sehen Sie ein XML-Beispiel und die dazugehörige hierarchische
Struktur des Dokuments.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<? xml version = " 1.0 " ? >
< bekannte >
< freunde >
< freund >
< vorname > Adam </ vorname >
< nachname > Maier </ nachname >
</ freund >
< freund >
< vorname > Tim </ vorname >
< nachname > Schuster </ nachname >
</ freund >
</ freunde >
< verwandte >
< verwandter typ = " eltern " >
< nachname > Mueller </ nachname >
< vorname > Mia </ vorname >
</ verwandter >
</ verwandte >
</ bekannte >
Quellcode 2.6: XML-Dokument
Abbildung 2.1.: XML-Hierarchie (Beispiel)
8
2. Grundlagen
2.2.3.1. Wohlgeformtheit
Es gibt für ein XML-Dokument zwei Kriterien, die es zu erfüllen gilt, um korrekt zu
sein. Zum einen muss ein XML-Dokument wohlgeformt sein, sprich den XML-Regeln
für Attribute und Tags entsprechen. Andererseits muss ein XML-Dokument auch valide sein. Zunächst wird die Wohlgeformtheit behandelt, die Validität folgt in Abschnitt
2.2.3.2.
Ein XML-Dokument muss immer mit der XML-Deklaration beginnen. In dieser muss
mindestens die Version angegeben werden, die anderen beiden Attribute sind optional.
Manche Anwendungen, wie der Internet Explorer 9 [25], setzen die XML-Deklaration
selbstständig, sollte der Autor diese vergessen haben.
Neben der XML-Deklaration muss ein XML-Dokument immer mindestens ein Element beinhalten: das Wurzelelement. Es darf dabei immer nur ein Wurzelelement geben.
Bei der Namensgebung von Tags und Attributen sollte darauf geachtet werden, dass
XML zwischen Groß- und Kleinschreibung unterscheidet. Dementsprechend müssen das
Start- und das End-Tag gleich geschrieben werden. </data> kann demnach kein <DaTa>Tag schließen.
Für Attribute gilt, dass ihre Werte immer mit Anführungszeichen versehen werden
müssen und auch immer nur einmal pro Tag vorkommen dürfen. Folgende Konstruktion
ist demnach nicht korrekt:
1
2
3
4
< tags >
< master id = " 1 " / >
< slave name = " aa " name = " bb " / >
</ tags >
Quellcode 2.7: Beispiel für falschen Attributgebrauch
Um ein wohlgeformtes Dokument zu gewährleisten, dürfen Tags nicht offen gelassen
werden. Das heißt, dass jedes Tag, das einmal geöffnet wurde, auch wieder geschlossen
werden muss. Dies gilt auch dann, wenn das Tag keine Daten enthält, es sich also um
ein leeres Tag handelt.
Wie bereits in Abschnitt 2.2.3 erklärt, können Tags verschachtelt werden. Hier gilt
es, im Sinne der Wohlgeformtheit zu beachten, dass wenn ein Tag innerhalb eines anderen geöffnet wurde, es auch innerhalb dieses Tags wieder geschlossen werden muss.
Konstrukte wie folgendes sind demnach nicht zulässig:
1
2
3
4
< master >
< slave >
</ master >
</ slave >
Quellcode 2.8: Beispiel für falsche Verschachtelung
9
2. Grundlagen
Es ist weiterhin verboten, Kommentare innerhalb von Tags zu platzieren.
Der letzte wichtige Punkt, den es zu beachten gilt, behandelt die Sonderzeichen und
die Namensgebung. Sonderzeichen dürfen im Datenbereich nur entsprechend kodiert oder
in einem speziellen CDATA-Bereich auftauchen.
1
2
3
4
5
6
< tags >
< zeichen1 > <! [ CDATA [
Inhalt mit Sonderzeichen: !\{[ ]}) /{ s }\ ’*
]] > </ zeichen1 >
< zeichen2 > whatever & copy ; </ zeichen2 >
</ tags >
Quellcode 2.9: Beispiel für den Einsatz eines CDATA-Bereichs
Sollen für die Werte von Attributen Sonderzeichen verwendet werden, so müssen diese
kodiert werden. CDATA kann hier nicht verwendet werden.
Anders verhält es sich mit den Namen für Attribute und Tags. Hier dürfen nahezu
alle Sonderzeichen verwendet werden, die der Zeichensatz, der in der XML-Deklaration
angegeben wurde, zulässt. Es gibt einige Ausnahmen wie Anführungszeichen und Klammern; diese können jedoch an anderer Stelle nachgelesen werden [10] und sind nicht
Gegenstand dieser Arbeit.
Eine weitere Vorgabe bezüglich der Namen ist die, dass die Namen nicht mit Ziffern,
einem Bindestrich oder einem Punkt beginnen dürfen, auch wenn diese Zeichen regulär
sind. [11][10][30]
2.2.3.2. Validität
Das zweite Kriterium für ein korrektes XML-Dokument ist die Validität. Ein Dokument ist valide, wenn alle Tags und Attribute den festgelegten Strukturregeln entsprechen. Diese Regeln lassen sich mithilfe von Struktursprachen, wie DTD [20] oder XML
Schema [32][28], definieren.
Diese Sprachen ermöglichen es festzulegen, welche Tags ein Dokument enthalten muss
oder in wie weit die Tags miteinander verschachtelt werden. Auch welche Attribute in
einem Tag enthalten sein müssen oder wie der Inhalt der Tags auszusehen hat kann
festgelegt werden. Werden diese Regeln nicht eingehalten, so ist das Dokument nicht
valide.
Das Festlegen einer Struktur und die entsprechende Prüfung dienen der Standardisierung der Dokumente. Diese ist beispielsweise bei der Kommunikation zwischen verschiedenen Anwendungen sinnvoll. So wird sichergestellt, dass nur Dokumente, die alle notwendigen Informationen, in entsprechender Form, beinhalten, angenommen werden. Zum
Beispiel wird eine Applikation, die SVG-Dateien [14] verarbeiten soll, keine XHTMLDateien [40] annehmen. Diese entsprechen nicht den Strukturregeln. [11][10]
10
2. Grundlagen
Die Validierung von XML-Dokumenten spielt in dieser Arbeit keine Rolle. Weitere
Informationen zur Validierung von XML-Dokumenten, der DTD und dem XML-Schema
finden sich auf der Website des W3C [20][32][28].
2.3. XML-Bibliotheken
Klassenbibliotheken sind Bibliotheken, die fertige Programmkomponenten enthalten.
Diese Bibliotheken enthalten meistens Klassen, die für einen gemeinsamen Zweck erstellt wurden. So auch die XML-Bibliotheken. Die darin enthaltenen Klassen erfüllen den
Zweck, XML-Dokumente einzulesen, zu verarbeiten und aus-, beziehungsweise weiterzugeben. Sie sind ein wesentlicher Bestandteil der XML-Programmierung. Für gewöhnlich
bestehen sie aus einem Parser, einer Verarbeitungskomponente und einer Ausgabekomponente.
Ein Parser ist ein Programm, das ein Dokument eines bestimmten Typs liest. Dieser
Vorgang wird auch einlesen oder parsen genannt. Die daraus gewonnenen Daten können
anschließend an eine andere Applikation weitergegeben werden. Im Falle einer XMLBibliothek parst der Parser XML-Dateien. Es wird zwischen validierenden und nichtvalidierenden Parsern unterschieden. Nicht-validierende Parser lesen ein XML-Dokument
nur ein, validierende Parser überprüfen zusätzlich die Validität (siehe Abschnitt 2.2.3.2)
eines XML-Dokumentes.
Die Prüfung der Validität ist nicht das einzige Kriterium zur Unterscheidung von
XML-Parsern. Auch die Art und Weise, wie der Parser die Dokumente verarbeitet, spielt
eine Rolle. So gibt es, neben der textbasierten Variante, bei der das Dokument wie eine
herkömmliche Textdatei verwendet wird, noch weitere, deutlich effizientere Verarbeitungswege. Die beiden wichtigsten Ansätze sind hierbei die Simple API for XML (SAX)
und das Document Object Model (DOM). [11]
DOM ist ein Standard des World Wide Web Consortium. Beim Vorgang des Parsens wird hierbei Stück für Stück ein Baum erstellt. Dieser wird auch Dokumentenbaum
oder DOM-Tree genannt. Das DOM bietet diverse Möglichkeiten an, auf diesen Baum
zuzugreifen und die Daten zu manipulieren. Mit Hilfe des DOMs können auch eigene
Dokumente erzeugt werden. [33]
SAX hingegen ist ein auf Events basierender Parser. Er erzeugt beim Lesen des Dokumentes unterschiedliche Events für unterschiedliche Objekte innerhalb der Datei. Auf
diese Events kann ein Entwickler dann zugreifen. Es ist zwar wesentlich schneller als
DOM, jedoch kann SAX die Daten nicht manipulieren. In dieser Arbeit liegt der Schwerpunkt auf DOM.
Der Parser übergibt die Daten nach erfolgreichem Parsen an eine Verarbeitungskomponente. Diese Komponente wandelt die Daten des Parser in eine Form um, in der sie
manipuliert werden können. Eine mögliche Form ist eine Baumstruktur. Anschließend
kann sie auf die Daten zugreifen und sie bearbeiten.
11
2. Grundlagen
Die Ausgabekomponente dient dazu, die Daten, die sie von der Verarbeitungskomponente erhält, zu serialisieren. Nachdem diese serialisiert wurden, kann sie diese ausgeben
oder beispielsweise in eine Datei schreiben. [2]
Abbildung 2.2.: Aufbau einer XML-Bibliothek
In Abbildung 2.3 wird der oben beschriebene Aufbau einer XML-Bibliothek verdeut-
12
2. Grundlagen
licht.
XML-Bibliotheken werden für gewöhnlich als Teil einer Anwendung eingesetzt. Dort
werden die benötigten Informationen mithilfe des Parsers eingelesen. Die Verarbeitungskomponente manipuliert die Daten und die Ausgabekomponente gibt die Daten anschließend an die Anwendung weiter. Diese wiederum verarbeitet die Informationen und
schickt ihrerseits XML-Nachrichten zurück an den Parser.
In den folgenden Abschnitten werden kurz die beiden Bibliotheken vorgestellt, die in
dieser Arbeit benutzt wurden.
2.3.1. Apache Xerces Java (Xerces)
Bei Apache Xerces Java, kurz Xerces, handelt es sich um eine in Java geschriebene Open-Source XML-Bibliothek der Apache Software Foundation. Sie kann XMLDokumente einlesen und bearbeiten. Auch die Validierung der Dokumente wird von
ihr unterstützt.
Das Projekt entstand 1999 als Teil des XML-Projektes, das IBM an Apache übergab.
Sein Ziel war und ist es, die Bekanntheit von XML zu steigern und für dessen Verbreitung
zu sorgen. Derzeit steht diese Bibliothek in der Version 2.11.0 zur Verfügung.
Xerces unterstützt DOM, SAX, JAXP, XML Schemata, XSD, SCD, Namespaces und
noch weitere XML-Technologien. Sie kann außerdem beide XML-Versionen bearbeiten.
[34]
Bei Xerces2-J handelt es sich, laut Herstellerseite, um eine nahezu vollständige Neufassung der Xerces XML-Bibliothek. Daher fiel die Entscheidung, welche Versionen für
die Untersuchung benutzt werden sollten, auf die jeweils aktuellste Version von sowohl
Xerces-J, als auch Xerces2-J. [34]
2.3.2. Microsoft XML Core Services (MSXML)
Microsoft XML Core Services oder auch MSXML ist eine XML-Bibliothek. Sie ermöglicht es, Programme mit XML-Unterstützung unter Windows zu programmieren.
MSXML ist bereits in diversen Produkten Microsofts enthalten. So auch in der aktuellen Version ihres Betriebssystems Windows 7 [21]. Unterstützte Sprachen sind C++,
VBScript und JScript.
Die Versionen 3.0, 4.0 und 6.0 werden von Microsoft unterstützt. Microsoft hat die
Versionen 4.0 und 6.0 zwar als Updates veröffentlicht, dennoch ersetzen sie Version 3.0
nicht. Da die drei Versionen sich in ihrem Funktionsumfang unterscheiden, ist es möglich,
auf einem System alle drei zu benutzen. [24]
MSXML beherrscht unter anderem DOM, SAX, Namespaces, XML Schemata, XSLT
und noch einige andere XML-Technologien, wie SOM. Auffallend ist, dass MSXML nur
XML Version 1.0, nicht aber Version 1.1 unterstützt. [23]
13
2. Grundlagen
Bei der Implementierung der XML-Bibliotheken wurde im Falle von MSXML auf
die Versionen 3.0 und 6.0 zurückgegriffen. 3.0 ist hierbei die älteste noch unterstützte
Version, wohingegen 6.0 die aktuellste Version dieser XML-Bibliothek ist.
14
3. Vorgehensweise
Im Rahmen der Untersuchung wurde ein XML-Dokument von den unterschiedlichen
XML-Bibliotheken eingelesen, verarbeitet und wieder ausgegeben. Anschließend wurden
die Ausgabedokumente nach gewissen Mustern untersucht und mit dem Originaldokument verglichen.
Dieses Kapitel erläutert, was es für Besonderheiten in XML gibt, auf die bei der
Untersuchung geachtet wurden und wie nach ihnen gesucht wird. Zum einen können sich
XML-Dokumente inhaltlich unterscheiden, jedoch strukturelle Unterschiede aufweisen.
Weiterhin gibt es das sogenannte Prettyprint, welches Einfluss auf die Formatierung der
Dokumente nimmt.
Die strukturellen Unterschiede von XML-Dateien und Prettyprint werden in den folgenden Abschnitten behandelt.
3.1. Strukturelle Unterschiede
Es ist in XML möglich, zwei semantisch gleiche Dokumente zu haben, die sich aber auf
der Text-Ebene unterscheiden. Dieser Fall tritt auf, wenn beide Dokumente dieselben
hierarchischen Ebenen und darin dieselben Knoten haben, jedoch die Knoten in der
Reihenfolge vertauscht worden sind. Hierzu ein kleines Beispiel:
1
2
3
4
5
6
7
8
9
10
11
12
<! -- Document No . 1 -- >
< hierarchy >
< First / >
< Second / >
< Third / >
</ hierarchy >
<! -- Document No . 2 -- >
< hierarchy >
< Second / >
< Third / >
< First / >
</ hierarchy >
Quellcode 3.1: Beispiel Strukturunterschiede
Im Quellcode 3.1 ist erkennbar, dass beide Dokumente hierarchisch gleich aufgebaut
sind. Beide haben ein Wurzelelement, welches drei weitere Elemente beinhaltet. Die drei
Elemente besitzen auch in beiden Dokumenten dieselben Namen, jedoch wurden sie in
anderer Reihenfolge gespeichert. Semantisch sind diese beiden Dokumente identisch, da
15
3. Vorgehensweise
sie denselben Inhalt aufweisen. Dennoch unterscheiden sich die beiden Dokumente.
Zusätzlich können sich Dokumente in der Anordnung ihrer Attribute unterscheiden.
XML lässt nahezu freie Wahl beim Setzen von Attributen. Es ist möglich, beliebig viele
Attribute in ein Tag einzufügen. Die Attribute können frei sortiert werden. Daher ist
auch dies ein Punkt, in dem sich XML-Dokumente unterscheiden können, wie folgendes
Beispiel aufzeigt:
1
2
3
4
5
6
7
8
<! -- Document No . 1 -- >
< hierarchy >
< First one = " 1 " two = " 2 " three = " 3 " / >
</ hierarchy >
<! -- Document No . 2 -- >
< hierarchy >
< First two = " 2 " one = " 1 " three = " 3 " / >
</ hierarchy >
Quellcode 3.2: Beispiel Strukturunterschiede II
Auch hier, in Quellcode 3.2, ist zu sehen, dass hier zwei inhaltlich gleiche Dokumente
vorhanden sind, die sich allein in der Reihenfolge der angelegten Attribute unterscheiden.
Relevant für die Untersuchung ist hierbei herauszufinden, ob eine der XML-Bibliotheken
eventuell die Reihenfolge der Elemente oder Attribute verändert, beziehungsweise sortiert. Da XML menschenlesbar ist, wird dies durch Vergleich der Quell- und der Ausgabedatei überprüft.
3.2. Formatierung und Prettyprint
XML-Dokumente können sich nicht nur inhaltlich und strukturell unterscheiden. Es
ist auch möglich, die Dokumente unterschiedlich zu formatieren.
Hierbei spielt das sogenannte Prettyprint eine wichtige Rolle. Bei Prettyprint handelt es sich um eine Formatierungskonvention für Programmiercode. Diese Konvention
besagt, dass Quellcode leserlich formatiert werden sollte. Elemente aus hierarchischen
Strukturen, wie in einem XML-Dokument, sollten beispielsweise entsprechend ihrer Ebene innerhalb der Struktur eingerückt werden:
1
2
3
4
5
< hierarchy >
< levelOne >
< levelTwo / >
</ levelOne >
</ hierarchy >
Quellcode 3.3: Prettyprint-Beispiel
Diese Einrückungen werden meist unterschiedlich realisiert. Ebenen werden jedoch in
der Regel durch einen Tabulator, oder aber durch mehrere Leerzeichen eingerückt.
16
3. Vorgehensweise
Jedoch ist nicht nur die leserliche Einrückung der Elemente relevant für die Untersuchung der Formatierung. Es gibt noch weitere Punkte in der Formatierung, die sehr
unterschiedlich gehandhabt werden.
Leere Tags sind einer dieser Punkte. Es ist möglich, leere Tags, wie bereits in Kapitel
2.2.3 beschrieben, unterschiedlich darzustellen. Entweder werden sie durch zwei Tags,
die keinen Inhalt haben, wie <tag></tag>, dargestellt oder direkt über ein einzelnes
leeres Tag, wie <tag />.
Ein weiteres wesentliches Merkmal, an dem die Dokumente unterschieden werden können, ist die Umsetzung von Sonderzeichen. Hierbei gilt es zwischen inhaltlichen Sonderzeichen und Formatierungs-Sonderzeichen zu unterscheiden.
Die inhaltlichen werden gewöhnlich in CDATA-Blöcken untergebracht. Es gibt jedoch
unterschiedliche Art und Weisen sie darzustellen. Sie können entweder direkt hineingeschrieben werden ($) oder HTML-konform kodiert werden ($). Auch in der Kodierung der Zeichen kann es Unterschiede geben. Diese hängen in der Regel vom zugrunde
liegenden Betriebssystem oder dem verwendeten Editor ab.
Mit Formatierungs-Sonderzeichen sind Tabulatoren, Leerzeichen und Zeilenumbrüche
gemeint. Diese werden auf verschiedenen Systemen und in verschiedenen Editoren unterschiedlich interpretiert. Der Zeilenumbruch ist beispielsweise ein Zeichen, für das es
drei gängige Arten gibt es zu kodieren. Während unter Apples Mac OS 9 [1] der Zeilenumbruch durch ein sogenanntes Carriage Return, beziehungsweise <CR>, kodiert
wird, so wird er unter Linux [16] durch einen Zeilenvorschub (<LF>) umgesetzt. Microsoft hingegen hat den Zeilenumbruch in ihrem Betriebssystem Windows [21] durch eine
Kombination der beiden Zeichen umgesetzt. [6]
Daher könnte es sein, dass, wenn ein Dokument auf einem Linux-System erzeugt wurde, es auf einem Windows-System anders dargestellt wird.
Die oben genannten Formatierungsmerkmale lassen sich nur begrenzt mit herkömmlichen Editoren wie Notepad++ [5] und PSPad [15] untersuchen. Dies liegt daran, dass
diese Editoren alle eine eigene Art haben, bestimmte Zeichen zu interpretieren und darzustellen. Für eine erste, grobe Untersuchung können diese Editoren benutzt werden.
PSPad bietet zusätzlich noch eine Funktion, die Dokumente vergleicht und die Unterschiede farblich markiert.
Die genaue Untersuchung der Formatierung der Dokumente muss aber mit verlässlicheren Hilfsmitteln geschehen. Hierfür wird ein Hex-Editor benutzt. Editoren dieser
Art ermöglichen es, die Formatierung von Dokumenten auf Byte-Ebene zu betrachten.
Ein Byte speichert Informationen über ein Zeichen ab. Es legt fest, um was für ein Zeichen es sich handelt. Mit einem Hex-Editor kann betrachtet werden als was das Zeichen
tatsächlich gespeichert wurde, unabhängig von der Interpretation eines Editors.
17
3. Vorgehensweise
3.3. Verwendete Suchmuster
Um die späteren Änderungen der Formatierung besser nachvollziehen zu können, folgt
mit Quellcode 3.4 ein Auszug aus der verwendeten Originaldatei, in der alle Suchmuster
aufgelistet sind.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
< tests >
<! -- tests attribute order -- >
< attributTest >
< tag att7 = " 0 " att2 = " 1 " wasd = " 546 " att4 = " " wertz = " empty " att1 =
" text " / >
</ attributTest >
<! -- tests tag order -- >
< orderTest >
[...]
< orderTags >
b 
<c >c </ c >
<z / > <a >a </ a >
< mass >
< aa > </ aa >
< bb / >
</ mass >
</ orderTags >
</ orderTest >
<! -- tests prettyprint without spaces -- >
< test > <a > <c / > 
21
22
23
24
25
26
</ a > </ test >
<! -- tests spaces , linebreaks and tabulators as attribute value
and tag value -- >
< formatTest >
< linebreak att = "
">
27
28
29
30
31
32
33
34
35
36
37
38
</ linebreak >
< tabulator att = " " >
</ tabulator >
< spaces att = "
">
</ formatTest >
<! -- tests cdata -- >
< cdataTest >
< cdata > <! [ CDATA [!"[... ]] ] > </ cdata >
</ cdataTest >
[...]
</ tests >
</ spaces >
Quellcode 3.4: Auszug aus dem Originaldokument
18
3. Vorgehensweise
Quellcode 3.4 zeigt die unterschiedlichen Muster auf, nach denen gesucht wurde. Zunächst wurde in der attributTest-Sektion das Sortierverhalten in Bezug auf die Attribute
getestet. Manche Bibliotheken sortieren die Attribute alphabetisch. Sie wurden daher im
Originaldokument bewusst in einer nicht-alphabetischen Reihenfolge angeordnet, damit
es gegebenenfalls sofort auffiele, wenn eine Bibliothek diese Reihenfolge ändert.
In der Sektion orderTest sollte einerseits getestet werden, ob die Reihenfolge der Tags
angepasst wird. Andererseits sollte überprüft werden, wie die Bibliothek mit leeren Tags
umgeht.
Die test-Sektion untersuchte das Verhalten, wenn eine Reihe von Tags ohne Leerzeile
oder sonstige Trennzeichen aneinandergereiht worden sind. Hierbei sollte darauf geachtet
werden, ob die Bibliotheken diese Tags voneinander trennen und gemäß Prettyprint
einrücken.
Im Abschnitt des formatTests liegt der Fokus auf Sonderzeichen wie Leerzeichen, Tabulatoren und Zeilenumbrüchen. Diese Zeichen wurden jeweils einmal zwischen den Tags
und als Attributwert verwendet, um zu überprüfen, ob die Bibliotheken diese Zeichen
als Werte akzeptieren.
In der letzten Sektion, der cdataTest-Sektion, sollte überprüft werden, wie die Bibliotheken den Rest der Sonderzeichen, wie $, # und &, behandeln.
Im Originaldokument befindet sich noch ein massTest-Abschnitt. Dieser wurde aus
Platzgründen nicht in Quellcode 3.4 aufgeführt. Er wurde erstellt um zu überprüfen,
wie die Bibliotheken reagieren, wenn über 1000 Tags nahezu gleicher Art hinzugefügt
werden.
Das folgende Kapitel erklärt die Durchführung dieser Untersuchung.
19
4. Durchführung
Im folgenden Kapitel soll das allgemeine Vorgehen bei der Implementierung einer
XML-Bibliothek erläutert werden. Doch zunächst werden das System, auf dem die Untersuchungen durchgeführt wurden, sowie die benutzten Werkzeuge beschrieben.
4.1. Benutztes System
Die Untersuchungen wurden alle auf demselben System durchgeführt. Es handelte sich
hierbei um ein Microsoft Windows 7 -System [21]. Die XML-Datei, die für die Untersuchungen verwendet wurde, wurde mit dem Editor Notepad++ [5] erstellt. Die Umsetzung
der XML-Bibliotheken in Code-Form erfolgte bei Xerces mit Hilfe der Entwicklungsumgebung Eclipse Helios [36]. Für MSXML wurde das Microsoft Visual Studio 2010 [22]
benutzt. Zur detaillierten Untersuchung der Formatierung der Ausgabedokumente wurde
der NEXT-Soft Hex-Editor MX benutzt [26].
4.2. Nutzung einer XML-Bibliothek
Dieser Abschnitt zeigt, am Beispiel von Xerces 1.4.4, wie die XML-Bibliothek implementiert wurde, damit sie das erstellte XML-Dokument verarbeitete.
Das Prinzip ist bei allen XML-Bibliotheken identisch. Zunächst muss ein Parser erstellt werden. Dieser liest das Dokument ein und erzeugt den Dokumentenbaum. Dieser
Baum kann anschließend manipuliert werden. Bevor die Informationen ausgegeben werden können, muss der Baum serialisiert werden. Die Serialisierung geschieht in der Regel
über eine eigene Klasse. Der resultierende String kann anschließend weiter- oder ausgegeben werden.
Als erstes wurde die XML-Bibliothek in der Version 1.4.4 von der Herstellerseite
[35] heruntergeladen und in einen entsprechenden Ordner entpackt. Dann wurde ein
Projekt mit dem Namen „Xerces-J 1.4.4“ erstellt. Dort musste zunächst die XercesKlassenbibliothek in das Projekt integriert werden. Dies geschieht in den Projekteinstellungen in der Kategorie „Java Build Path“. Dort wurden, wie in Abbildung 4.2 zu sehen,
die notwendigen JAR-Dateien hinzugefügt. In dem Fall der Xerces 1.4.4-Bibliothek war
dies eine einzige Datei namens xerces.jar.
20
4. Durchführung
Abbildung 4.1.: Einbinden der Xerces-Bibliothek
Nun folgte die eigentliche Implementierung. Erst musste der Parser erstellt werden.
Hierfür wurde ein DOM-Parser verwendet. Es wurde ein Objekt parser des Typs DOMParser erstellt und initialisiert. Danach war dieser bereits einsatzfähig und es musste
lediglich die entsprechende Methode parse(String) aufgerufen werden. Wird dieser Methode die Adresse der XML-Datei als String übergeben, so liest der Parser diese Datei
ein.
Mit einem anschließenden Aufruf der Methode getDocument() wurde ein Dokumentenbaum erzeugt. Dieser kann zum Zugriff und zur Bearbeitung einzelner Elemente verwendet werden. Er wird als Document-Objekt übergeben.
Im nächsten Schritt musste der Dokumentenbaum serialisiert werden. In serialisierter
Form lässt sich ein Dokumentenbaum ausgeben oder in eine Datei schreiben. Zur Serialisierung wurde ein Objekt serializer des Typs XMLSerializer erzeugt. In diesem Objekt
werden sowohl Ausgabequelle, als auch Ausgabeformat festgelegt. Das Format wird zum
Beispiel festgelegt, indem ein Objekt des Typs OutputFormat erzeugt und übergeben
wird. Mit Hilfe von OutputFormat ist es möglich, das Einrücken an- oder auszuschalten, was quasi Prettyprint entspricht. Hierzu muss nur ein entsprechender Aufruf der
21
4. Durchführung
Methode setIndenting() erfolgen.
Die Ausgabequelle wurde mit der Funktion setOutputCharStream(StringWriter) definiert. Im übergeben Objekt des Typs StringWriter wird nach erfolgreicher Serialisierung
der Dokumentenbaum als String gespeichert.
Der eigentliche Serialisierungsvorgang wird durch den Aufruf serializer.serialize(xmlDoc)
realisiert. Dem serializer-Objekt wird hierbei das vorher erstellte Document-Objekt übergeben.
Der resultierende String kann nun entweder ausgegeben oder in via BufferedWriter in
eine Datei gespeichert werden. Im Falle dieser Untersuchung wurde der String in eine
Datei geschrieben und gespeichert.
Diese Datei wurde anschließend auf die in Kapitel 3 beschriebenen Muster untersucht.
Diese Untersuchung der einzelnen Ausgabedokumente wird im folgenden Kapitel beschrieben.
Die für die folgende Untersuchung relevanten Dokumente wurden jeweils durch eine der vier XML-Bibliotheken erstellt. Bei MSXML3.0 und MSXML6.0 wurden dabei
gänzlich die Standardeinstellungen benutzt. Bei Xerces 1.4.4 und Xerces 2.11.0 wurden
die Dokumente je einmal mit Standardeinstellungen und einmal mit eingeschaltetem
Prettyprint untersucht.
22
5. Untersuchung
Dieses Kapitel beschäftigt sich mit der Untersuchung der Ausgabedokumente der einzelnen XML-Bibliotheken. Die Formatierung dieser Dokumente steht dabei im Vordergrund. Diese Untersuchung bildet die Grundlage für die spätere Evaluation.
Es wurden bei der Untersuchung nach den in Kapitel 3 vorgestellten XML- und formatierungsspezifischen Eigenarten gesucht.
5.1. Xerces
Bei Xerces handelt es sich um eine XML-Bibliothek, die in Java geschrieben wurde.
Zum Zeitpunkt der Untersuchung lag Xerces in der Version 2.11.0 vor. Diese Version,
wie auch die Version 1.4.4, wurden im Rahmen der Untersuchung implementiert.
5.1.1. Xerces-J 1.4.4
Betrachtet man das Ausgabedokument, das mit Hilfe von Xerces Version 1.4.4 erstellt
wurde, so fällt auf, dass standardmäßig kein Prettyprint angewandt wurde. Dieses lässt
sich, wie in Kapitel 4 beschrieben, an- und abschalten. Zunächst wird beschrieben, was
für Auffälligkeiten das Dokument bei eingeschaltetem Prettyprint aufweist.
Als erstes fällt auf, dass Xerces das Ausgabedokument unabhängig von der im Originaldokument vorhandenen Formatierung formatiert. Leerzeichen, Tabulatoren und Zeilenumbrüche zwischen Tags werden gänzlich ignoriert.
Die einzelnen Passagen des Dokuments werden entsprechend der „Hierarchie“ des
Dokuments formatiert. Das heißt, dass die einzelnen Ebenen des Dokuments eingerückt
werden. Jedem Tag, das noch weitere Tags beinhaltet, wird ein Zeilenumbruch hinzugefügt. Auf diesen Zeilenumbruch folgen je vier Leerzeichen pro Ebene, die das Tag von der
Wurzel entfernt ist. Beinhaltet ein Tag keine weiteren Tags, so folgt der Zeilenumbruch
erst auf das zugehörige End-Tag. Auch dem End-Tag der Wurzel wird ein Zeilenumbruch
hinzugefügt.
Die XML-Deklaration wird, wie auch die Wurzel, nicht eingerückt. Unabhängig davon,
ob Prettyprint ein- oder ausgeschaltet ist, folgen ihr ein Zeilenumbruch und das ÖffnungsTag der Wurzel. Wurde im Ursprungsdokument keine gesetzt, wird dennoch eine XMLDeklaration im Ausgabedokument ausgegeben. Der XML-Deklaration wird das Attribut
23
5. Untersuchung
encoding hinzugefügt und der Wert auf „UTF-8“ [37] gesetzt. Dieses Attribut gibt an,
welcher Zeichensatz für das Dokument verwendet wird.
Eine Ausnahme für diese Regel gibt es: Wird kein OutputFormat bei der Implementierung festgelegt, so wird bei der XML-Deklaration das encoding-Attribut weggelassen.
Das Ausschalten von Prettyprint ist ansonsten identisch mit dem Weglassen des OutputFormat.
Sofern nicht anders im Quellcode angegeben, ersetzt Xerces den Wert des versionAttribut mit „1.0“. Eine Umstellung auf „1.1“ hat keine Auswirkungen auf das Ausgabeformat.
Es fällt weiterhin auf, dass Xerces die Attribute ihrer alphabetischen Reihenfolge nach,
sortiert. Tags hingegen werden nicht sortiert. Sie werden in der Reihenfolge übernommen,
in der sie im Originaldokument stehen.
Haben zwei zusammengehörende Tags keinen Inhalt, so werden sie durch ein leeres
Tag ersetzt. Befinden sich bereits leere Tags im Originaldokument, so werden sämtliche
überschüssigen Leerzeichen zwischen dem Tagnamen und Slash entfernt. Sollte ein TagPaar außer Leerzeichen, Tabulatoren oder Zeilenumbrüchen nichts beinhalten, so werden
diese beiden Tags durch ein einzelnes, leeres Tag ersetzt.
Wurden für den Wert eines Attributes Zeilenumbrüche oder Tabulatoren verwendet,
so werden diese durch Leerzeichen ersetzt. Folgen von Leerzeichen werden übernommen. Sonderzeichen, die in einem CDATA-Block stehen, werden weitestgehend auch im
Ausgabedokument übernommen. Es gibt jedoch einige Ausnahmen. Einige Zeichen, wie
beispielsweise § oder e, werden im Originaldokument anders kodiert als im Ausgabedokument. Im Originaldokument befinden sich Trennzeichen, wie Â (hexadezimalkodiert:
C2) vor diesen Zeichen. Xerces hat bei der Ausgabe diese Trennzeichen entfernt.
Die Entfernung der Trennzeichen hat zur Folge, dass XML-Parser, wie die im Internet
Explorer 9 [25] oder Google Chrome 11 [9] integrierten, das Ausgabedokument nicht
mehr einwandfrei einlesen.
Quellcode 5.1 zeigt einen Ausschnitt, in dem die eben erwähnten Merkmale vorzufinden sind. Am auffälligsten ist hier die Veränderung, die zwischen den <formatTest>-Tags
vorgenommen wird. Wie bereits oben beschrieben, werden die Tabulatoren, Leerzeichen
und Zeilenumbrüche zwischen Öffnungs- und End-Tag entfernt und die Tags durch leere Tags ersetzt. Es ist weiterhin erkennbar, dass bei leeren Tags unnötige Leerzeichen
zwischen Tag-Name und dem Slash („/“) entfernt wurden.
Auch wurden zwischen den <attributTest>-Tags die Attribute alphabetisch geordnet.
Es ist anzunehmen, dass Kommentare wie Tags behandelt werden, da sie auf die gleiche
Art und Weise eingerückt werden.
24
5. Untersuchung
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
< tests >
< attributTest >
< tag att1 = " text " att2 = " 1 " att4 = " " att7 = " 0 " wasd = " 546 " wertz
= " empty " / >
</ attributTest >
<! -- tests tag order -- >
< orderTest >
[...]
< orderTags >
b 
<c >c </ c >
<z / >
<a >a </ a >
[...]
</ orderTags >
</ orderTest >
<! -- tests prettyprint without spaces -- >
< test >
<a >

<c / >

</ a >
</ test >
<! -- tests spaces , linebreaks and tabulators as attribute value
and tag value -- >
< formatTest >
< linebreak att = " " / >
< tabulator att = " " / >
< spaces att = "
"/>
</ formatTest >
<! -- tests cdata -- >
< cdataTest >
< cdata > <! [ CDATA [!"[... ]] ] > </ cdata >
</ cdataTest >
[...]
</ tests >
Quellcode 5.1: Auszug der Ausgabedatei nach Xerces 1.4.4 mit Prettyprint
Bei ausgeschaltetem Prettyprint werden Tabulatoren und Zeilenumbrüche durch Leerzeichen ersetzt. Wie bereits beschrieben, wird nur der Zeilenumbruch nach der XMLDeklaration übernommen.
Die beiden Quellcodes 5.2 und 5.3 demonstrieren die beschriebene Formatierung.
25
5. Untersuchung
1
2
3
4
5
6
< tests >
< attributTest >
< tag att7 = " 0 " att2 = " 1 " wasd = " 546 " att4 = " " [...] / >
</ attributTest > [...]
</ tests >
Quellcode 5.2: kurzer Auszug aus dem Originaldokument
1
2
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
< tests > <! -- tests attribute order -- >
= " text " att2 = " 1 " att4 = " " [...]
< attributTest >
< tag att1
Quellcode 5.3: Auszug der Ausgabedatei nach Xerces 1.4.4 ohne Prettyprint
Wie in dem Quellcodebeispiel 5.3 zu sehen, besteht das ausgegebene Dokument nur noch
aus zwei Zeilen Code.
Abbildung 5.1.: Xerces 1.4.4 Hex-Editor-Ansicht (Zeilenumbruch markiert)
Wird das Dokument mit einem Hex-Editor (siehe Abbildung 5.1) betrachtet, so ist
erkennbar, dass die Zeilenumbrüche durch einen einfachen Zeilenvorschub kodiert werden. Diese Art des Zeilenumbruches wird gewöhnlich auf Linux-Systemen benutzt. Dies
ist interessant, da anzunehmen wäre, dass ein für Windows typischer Zeilenumbruch
verwendet werden würde, da das Versuchssystem Windows nutzt.
Im folgenden Abschnitt folgt die Untersuchung der Version 2.11.0 der Xerces XMLBibliothek.
5.1.2. Xerces2-J 2.11.0
Bei dem mit Hilfe von Xerces 2.11.0 erzeugten Dokument fällt als erstes auf, dass
automatisch eine XML-Deklaration erzeugt wurde. Der Zeichensatz wird in dieser standardmäßig auf „UTF-16“ gesetzt wird. Versucht man die Datei beispielsweise mit dem
Notepad++ [5] oder dem Internet Explorer 9 [25] einzulesen, so erscheint folgende Fehlermeldung:
26
5. Untersuchung
„XML Parsing error at line 1: Document labeled UTF-16 but has UTF-8 content“.
Um Fehler dieser Art zu vermeiden, wurde im weiteren Verlauf der Untersuchung
das encoding-Attribut der XML-Deklaration auf „UTF-8“ gesetzt. Das Setzen dieses
Attributes hat keine Auswirkungen auf die Formatierung der Ausgabedatei. Dies gilt
auch für das Ändern der XML-Version von Version 1.1 zu Version 1.0. Standardmäßig
setzt Xerces das version-Attribut auf 1.0.
Weiterhin ist auffallend, dass die XML-Deklaration und das Öffnungs-Tag der Wurzel
in derselben Zeile stehen und nicht durch einen Zeilenumbruch getrennt werden.
Die Anordnung der Tags der Ausgabedatei entspricht weitestgehend der Anordnung
im Originaldokument. Dies mag daher kommen, dass standardmäßig Prettyprint ausgeschaltet ist.
Auch in dieser Version werden Attribute alphabetisch sortiert und Tags ohne Inhalt
durch leere Tags ersetzt. Unnötige Leerzeichen nach dem Namen eines leeren Tags wurden ebenso entfernt.
Zeilenumbrüche, Leerzeichen und Tabulatoren werden in dieser Version von Xerces
als Inhalt zweier Tags akzeptiert. Verwendet man diese Zeichen jedoch als Wert von
Attributen, so werden diese durch Leerzeichen ersetzt.
Die wohl nennenswerteste Änderung ist die Handhabung der Sonderzeichen. Der CDATA-Block des Originaldokumentes wurde im Ausgabedokument weggelassen. Der Inhalt
des Blocks wurde, wie herkömmlicher Text, zwischen die cdata-Tags eingefügt. Die Zeichen wurden mit drei Ausnahmen so im Ausgabedokument übernommen, wie sie auch
im Originaldokument kodiert waren. Lediglich das &, sowie, die beiden spitzen eckigen
Klammern < und > wurden in HTML-Entitäten umgewandelt. & wurde demnach durch
„&“,< durch „<“ und > durch „>“ ersetzt.
Folgende Abbildung verdeutlicht die Änderungen des CDATA-Bocks:
Abbildung 5.2.: Vorher/Nachher - Vergleich des CDATA-Blocks
Bei Xerces 2.11.0 ist die Funktion Prettyprint standardmäßig ausgeschaltet. Wird es
eingeschaltet, so fällt auf, dass diese Funktion für unformatierte Dokumente gedacht
ist. Dies ist daran erkennbar, dass ähnlich formatiert wird wie schon bei Version 1.4.4,
jedoch die Zeilenumbrüche und Tabulatoren aus dem Originaldokument übernommen
werden.
Prettyprint macht sich nur da bemerkbar, wo Tags aneinandergereiht im Originaldokument stehen, ohne dass diese durch irgendwelche Zeichen getrennt werden. Diese
27
5. Untersuchung
Reihen werden Tag für Tag auseinandergebrochen. Hinter jedes Tag dieser Reihen werden ein Zeilenumbruch und drei Leerzeichen für jede Ebene, die zwischen dem Tag und
der Wurzel liegt, hinzugefügt. Dies gilt nur dann, wenn das Tag weitere Tags beinhaltet.
Ansonsten folgt der Zeilenumbruch auf das End-Tag, so auch bei der Wurzel. Folgendes
Bild veranschaulicht eben Beschriebenes im Vergleich des Original- und des Ausgabedokumentes:
Abbildung 5.3.: Vorher/Nachher – Vergleich bei Prettyprint
Es ist zu empfehlen, Prettyprint nur für vollkommen unformatierte XML-Dokumente
zu verwenden, da sonst die gewünschte Leserlichkeit abhanden kommt.
Abbildung 5.4.: Xerces 2.11.0 Hex-Editor-Ansicht II (Zeilenumbruch markiert)
28
5. Untersuchung
Werden die unterschiedlichen Zeichen mit einem Hex-Editor untersucht, wie in Abbildung 5.4, so fällt auf, dass ein für Windows typischer Zeilenumbruch verwendet wurde.
Hierbei handelt es sich um eine Kombination aus dem Zeilenvorschub und dem sogenannten Carriage Return (CRLF).
5.2. MSXML
MSXML ist eine von Microsoft erstellte XML-Bibliothek. Sie unterstützt unter anderem die Sprachen VBScript, C++ und JScript. Im Rahmen dieser Untersuchung wurden
die MSXML-Bibliotheken der Version 3.0 und 6.0 in C++ Projekte eingebunden.
5.2.1. MSXML3.0
Auf den ersten Blick scheint das Ausgabedokument der MSXML3.0 -Bibliothek leserlich, gemäß Prettyprint, formatiert worden zu sein. Bei genauerer Betrachtung fallen
jedoch Abweichungen auf.
Leerzeichen, Tabulatoren und Zeilenumbrüche werden beispielsweise nur als Wert für
Attribute akzeptiert und ausgegeben. An allen anderen Stellen im Dokument werden sie
durch einen Zeilenumbruch und n Tabulatoren ersetzt. n steht hierbei für die Anzahl
der Ebenen, die zwischen dem Element und der Wurzel liegen. Nach dem End-Tag der
Wurzel wird jedoch ein Zeilenumbruch eingefügt.
Auffällig hierbei ist, dass aneinanderhängende Tags bei der Einrückung als ein Element betrachtet werden. Sie werden nicht getrennt, sondern, wie wenn es sich um ein
einziges Tag handeln würde, eingerückt. Folgendes Beispiel veranschaulicht das eben
Beschriebene:
1
2
3
<! -- Code aus der Originaldatei -- >
< prettyprintTest >
< tagInTag > < emptyTag / >
4
5
6
< tagInTagInTag > < emptyToo / > </ tagInTagInTag >
< yetAnotherTag / >
7
8
9
10
11
12
13
14
15
16
< andHereAgain / >
</ prettyprintTest >
<! -- Beispiel aus MSXML3 .0 -- >
< prettyprintTest >
< tagInTag > < emptyTag / >
< tagInTagInTag > < emptyToo / > </ tagInTagInTag >
< yetAnotherTag / >
< andHereAgain / >
</ prettyprintTest >
Quellcode 5.4: MSXML-Formatierung
29
5. Untersuchung
Es ist gut zu erkennen, dass beispielsweise das <emptyTag/> nicht vom <tagInTag>
getrennt und anschließend eingerückt wurde.
MSXML3.0 sortiert weiterhin keine Attribute oder Tags. Sie werden allesamt so übernommen, wie sie im Originaldokument stehen. Auch Tag-Paare ohne Inhalt werden unangetastet übertragen. Es werden jedoch bei leeren Tags wie <bb /> die unnötigen
Leerzeichen zwischen dem Namen und dem Slash entfernt.
Auch Sonderzeichen, die in einem CDATA-Block stehen, werden im Ausgabedokument
so übernommen, wie sie auch im Originaldokument stehen.
Abschließend ist zu vermerken, dass MSXML3.0 keine XML-Deklaration hinzufügt,
wenn dies nicht explizit angegeben wird oder diese im Ursprungsdokument vorhanden
war. Auch wird der Zeilenumbruch Windows-typisch kodiert. Dies war jedoch vorher
abzusehen, da einerseits auf dem System ein Microsoft-Betriebssystem installiert ist und
andererseits eine Microsoft-Entwicklungsumgebung, sowie eine Microsoft-XML-ibliothek
genutzt wurden.
5.2.2. MSXML6.0
Die Untersuchung der Ausgabedatei von MSXML6.0 ergab, dass diese Datei nahezu
identisch ist mit der von MSXML3.0. Es gab einen einzigen Unterschied. Der Wert des
Attributes im <linebreak>-Tag wurde verändert.
Im Originaldokument befinden sich an der Stelle ein Windows-typischer Zeilenumbruch und ein Tabulator. Im MSXML6.0-Ausgabedokument befindet sich an dieser Stelle
die HTML-Entität 
 in Kombination eines Tabulators. Dieser Code steht ebenfalls für einen Zeilenumbruch, dennoch ist es ungewöhnlich, dass er in kodierter Form
im Dokument erscheint.
30
6. Evaluation
Wie bereits in den vorangegangenen Kapiteln 3 und 4, wurden zunächst die XMLBibliotheken Xerces und MSXML implementiert. Die resultierenden Programme lasen
ein vorher erstelltes XML-Dokument ein, wandelten es um, und schrieben es anschließend
in eine Datei. Diese Ausgabedateien wurden daraufhin mit verschiedenen Editoren auf
Unterschiede zum Originaldokument untersucht. Die Unterschiede, an denen man ein
Dokument einer Bibliothek zuordnen könnte, werden im Folgenden behandelt.
In Abschnitt 6.1 wird gezeigt, wie man anhand der Ausgabedokumente auf die jeweilige
Xerces-Version schließen kann. Abschnitt 6.2 zeigt dasselbe für die MSXML-Bibliothek.
Der direkte Vergleich der beiden Bibliotheken folgt dann in Abschnitt 6.3.
Im letzten Abschnitt wird beschrieben, wie ein Angreifer beim XML-BibliothekenFingerprinting vorzugehen hätte um Erfolg zu haben.
6.1. Xerces
Als erste XML-Bibliotheken wurden Version 1.4.4 und 2.11.0 der Apache Xerces XMLBibliothek untersucht. Genau genommen gab es je zwei Untersuchungen. Eine mit und
eine ohne Prettyprint.
Vergleicht man die Dokumente der beiden Bibliotheken, so fällt auf, dass auf die XMLDeklaration bei Version 2.11.0 standardmäßig kein Zeilenumbruch folgt. Somit beginnt
das Wurzeltag immer in derselben Zeile wie die XML-Deklaration.
Nutzt man als Originaldokument ein gänzlich unformatiertes Dokument zur Erstellung der Ausgabedokumente, dann fallen einige weitere Unterscheidungsmerkmale auf.
Zunächst wäre da die Länge der Dateien bei ausgeschaltetem Prettyprint: Version 1.4.4
schreibt eine XML-Deklaration, macht einen Zeilenumbruch und schreibt anschließend
die restlichen Daten alle in eine einzige Zeile. Die Zeichen werden dabei durch ein Leerzeichen für jede Ebene, die zwischen dem Tag und der Wurzel liegt, getrennt. In Version
2.11.0 hingegen wird alles in eine einzige Zeile geschrieben und die Tags werden auch
nicht voneinander getrennt.
Ein anderes Unterscheidungsmerkmal ist die Anzahl der benutzten Leerzeichen beim
Einrücken der Tags. Erstellt man die Ausgabedokumente bei eingeschaltetem Prettyprint, so merkt man, dass beide Versionen unterschiedlich viele Leerzeichen zum Einrücken benutzen. Während es bei Version 1.4.4 vier Leerzeichen sind, so nutzt Version
2.11.0 nur drei. Diese Anzahl lässt sich jedoch in den Einstellungen umstellen. Daher
31
6. Evaluation
ist dies kein zuverlässiges Erkennungsmerkmal. Jedoch fällt weiterhin auf, dass Version 2.11.0 vorhandene Formatierungszeichen wie Tabulatoren und Zeilenumbrüche übernimmt. Da es keine Tabulatoren in durch Xerces 1.4.4 erstellten Dokumenten gibt, ist
auch dies ein Kennzeichen, an dem man die Version ausmachen kann.
Zwei Merkmale helfen jedoch eindeutig bei der Unterscheidung. Einerseits die XMLDeklaration, deren encoding-Attribut standardmäßig auf „UTF-16“ gesetzt ist. In Kombination mit dem fehlenden Zeilenumbruch am Ende der Deklaration und der Version,
welche sich von der in Xerces 1.4.4 angegeben unterscheidet, ist dies durchaus eine eindeutige zuzuordnende Eigenart von Xerces 2.11.0. Das andere Merkmal ist die Handhabung der CDATA-Blöcke. Version 2.11.0 entfernt diese und schreibt die Sonderzeichen
direkt zwischen die Tags, als wären sie herkömmliche Textstrings. Dabei werden &, <
und > Zeichen kodiert ausgegeben. Xerces 1.4.4 entfernt hingegen die Trennzeichen vor
manchen Sonderzeichen. Dies ist jedoch mit herkömmlichen Editoren nicht erkennbar.
Hierfür muss ein Hex-Editor benutzt werden.
Die Zeilenumbrüche sind ein weiteres, kennzeichnendes Merkmal. Sie werden in Xerces
1.4.4 durch einen einfachen Zeilenvorschub realisiert, während Xerces 2.11.0 dies durch
eine Kombination aus Carriage Return und Zeilenvorschub macht. Bei Version 2.11.0
ist anzunehmen, dass der Zeilenumbruch abhängig vom System kodiert wird, da sich
Java-Applikationen für gewöhnlich an das zugrunde liegende System anpassen.
6.2. MSXML
Vergleicht man die Ausgabedokumente der beiden XML-Bibliotheken MSXML3.0 und
MSXML6.0, so können diese nicht immer sofort unterschieden werden. Auf den ersten
Blick sehen diese beiden Dokumente identisch aus. Achtet man jedoch auf die Umsetzung
von Sonderzeichen als Attributinhalte, dann fällt etwas auf. MSXML6.0 ersetzt Zeilenumbrüche, die als Attributwert gesetzt wurden, durch eine HTML-Entität: 
.
6.3. Die XML-Bibliotheken im Vergleich
Nicht nur innerhalb der Versionen unterscheiden sich die getesteten Bibliotheken, auch
herstellerübergreifend gibt es Identifikationsmerkmale. Ein solches sind hierbei die Attribute. Während MSXML-Bibliotheken diese so übernehmen, wie sie im Originaldokument
stehen, sortieren die Xerces-Bibliotheken diese alphabetisch.
Ein weiteres Kriterium, an dem MSXML- von Xerces-Bibliotheken unterschieden werden können, ist die Umsetzung des Prettyprint. Während die auf Java basierenden Bibliotheken die Tags mit Leerzeichen einrücken, verwenden die MSXML-Bibliotheken
Tabulatoren.
Die MSXML-Versionen ersetzen, im Gegensatz zu den Xerces-Bibliotheken, keine TagPaare durch leere Tags, sollten diese keinen Inhalt besitzen. Außerdem lassen sie Zei-
32
6. Evaluation
lenumbrüche und Tabulatoren als Werte für Attribute zu. Diese werden in den XercesGegenstücken durch Leerzeichen ersetzt.
Hier werden nochmals die Merkmale zusammengefasst, die die jeweilige Bibliothek
von den anderen unterscheiden:
Xerces 1.4.4 lässt sich anhand der Kodierung der Zeilenumbrüche und diverser anderer
Sonderzeichen identifizieren. Das Einrücken der Elemente erfolgt durch Aneinanderreihung von Zeichenketten, bestehend aus vier Leerzeichen. Alternativ erkennt man es bei
ausgeschaltetem Prettyprint an der zweizeiligen Formatierung des Dokumentes.
Mithilfe der XML-Deklaration, der darin definierten UTF-16-Kodierung und dem fehlenden Zeilenumbruch lässt sich Xerces 2.11.0 eindeutig erkennen. Die ungewöhnliche
Umsetzung der CDATA-Blöcke in Sonderzeichen trägt ebenfalls dazu bei. Weiterhin ist
standardmäßig immer XML-Version 1.1 gesetzt. Bei unformatiertem Originaldokument
und ausgeschaltetem Prettyprint wird alles in eine Zeile geschrieben. Einrückung bei
angeschaltetem Prettyprint wird durch Zeichenketten, bestehend aus drei Leerzeichen,
realisiert.
MSXML3.0 kann daran erkannt werden, dass Tabulatoren und Zeilenumbrüche als Attributwerte zugelassen sind. Weiterhin werden zum Einrücken nur Tabulatoren benutzt,
keine Leerzeichen. Aneinanderhängende Tags werden nicht getrennt, sondern eingerückt,
als wären sie ein einziges Tag.
MSXML6.0 erkennt man an denselben Eigenschaften wie schon MSXML3.0. Diese beiden lassen sich anhand ihrer Attributwerte unterscheiden. Während MSXML3.0 Zeilenumbrüche als Attributwert akzeptiert, werden diese bei MSXML6.0 durch eine HTMLEntität ersetzt.
6.4. Suchmuster für Angreifer
Dieser Abschnitt soll nun erklären, welche Suchmuster ein Angreifer verwenden kann,
um anhand einer XML-Nachricht herauszufinden, welche XML-Bibliothek diese erzeugt
haben könnte.
Zunächst einmal empfiehlt es sich, auf die Formatierung der Ausgabe zu achten. Ist die
Ausgabe leserlich formatiert, könnte es sein, dass Prettyprint verwendet wurde. Wichtig
sind hierbei vor allem das verwendete Einrückungsschema, sowie die dabei verwendeten Zeichen. Manche Bibliotheken rücken mithilfe von Leerzeichen ein, manche nutzen
Tabulatoren. Auch auf zusammenhängende Tags sollte geachtet werden, da nicht jede
XML-Bibliothek diese trennt.
Mit einem Blick auf die XML-Deklaration könnten weitere XML-Bibliotheken ausgeschlossen werden. Steht in dem Dokument beispielsweise, dass XML-Version 1.1 verwendet wurde, so lässt dies den Schluss zu, dass kein MSXML genutzt wurde. Diese XMLBibliotheken unterstützen XML 1.1 nicht. Sollte im encoding-Attribut der Deklaration
ein ungewöhnlicher Wert wie „UTF-16“ stehen, so ist dies ein Punkt, an dem angesetzt
33
6. Evaluation
werden kann. Eine Möglichkeit wäre es, mit dieser Information nach XML-Bibliotheken
zu suchen, die (standardmäßig) diesen Zeichensatz unterstützen.
Eine weitere Möglichkeit um den Rahmen etwas einzugrenzen wäre es, sich die Attribute und Tags genauer anzusehen. Zunächst sollte überprüft werden, ob die Attribute
und Tags alphabetisch sortiert werden. Diese Funktion unterstützen nicht alle Bibliotheken. Zusätzlich kann geprüft werden, ob Tags, die keine Zeichen beinhalten, durch
leere Tags ersetzt werden und ob besagten leeren Tags unnötige Leerzeichen nach dem
Namen entfernt werden. Es sollte auch unbedingt untersucht werden, ob Leerzeichen,
Zeilenumbrüche oder Tabulatoren als Werte von Attributen oder als Inhalt von Tags zugelassen sind. Werden solche Zeichen an den entsprechenden Stellen entdeckt, so erlaubt
auch dies Schlüsse auf die zugrunde liegende XML-Bibliothek.
Das vielleicht wichtigste Suchkriterium sind die Sonderzeichen. Hierbei ist interessant,
wie diese behandelt und wie sie kodiert werden. Es gilt herauszufinden, in welcher Form
die Sonderzeichen im Dokument stehen. Vier Möglichkeiten gibt es, die Sonderzeichen
in der Ausgabe darzustellen. Die eine Variante ist die, dass die Sonderzeichen in einem
CDATA-Block stehen. Die nächste wäre, dass die Sonderzeichen in Form von HTMLEntitäten (zum Beispiel &) im Text stehen. Als drittes wäre es möglich, dass die
Zeichen, ohne CDATA-Block und ohne HTML-Kodierung, als gewöhnlicher Text dargestellt werden. Die letzte Variante wäre eine Kombination aus Variante eins und zwei
oder zwei und drei.
Die Sonderzeichen können sich jedoch nicht nur in der Art der Präsentation unterscheiden. Sie können auch unterschiedlich kodiert werden. Für eine Untersuchung der
Kodierung der einzelnen Zeichen wird ein Hex-Editor benötigt. Bei der Überprüfung der
Kodierung sollte vor allem auf die Zeilenumbrüche (Vergleich Kapitel 3) und Trennzeichen geachtet werden. Die Bibliotheken kodieren diese Zeichen sehr unterschiedlich oder
übernehmen sie, im Falle der Trennzeichen, nicht.
34
7. Abschluss
Dieses Kapitel gibt in Abschnitt 7.1 eine Zusammenfassung der Arbeit. In Abschnitt
7.2 werden die Ergebnisse und die daraus gewonnen Erkenntnisse präsentiert. Der Abschnitt 7.3 zeigt auf, welche Untersuchungen bisher noch nicht gemacht wurden, beziehungsweise welche noch gemacht werden sollten.
7.1. Zusammenfassung
Kapitel 2 lieferte die Grundlagen, die für das Verständnis dieser Arbeit notwendig
waren. In Kapitel 3 wurde zunächst erläutert, welche Unterschiede in der Struktur und
der Darstellung von XML-Dateien möglich sind. Im Anschluss wurde in Abschnitt 3.3
erklärt, wie diese untersucht werden sollten, damit eben diese Unterschiede aufgespürt
werden können. Kapitel 4 erklärte anhand eines Beispiels, wie eine XML-Bibliothek zu
implementieren ist. Es wurden weiterhin das für die Untersuchung verwendete System,
als auch die benutzten Werkzeuge vorgestellt.
Die eigentliche Untersuchung der Dokumente erfolgte in Kapitel 5. Dort wurden die
Ausgabedokumente der individuellen XML-Bibliotheken inspiziert, um gegebenenfalls
Muster zu entdecken, die bei der Erstellung entstanden sind.
In Kapitel 6 wurden die Ergebnisse der Untersuchung evaluiert. Hierbei wurden versionsspezifische, wie auch herstellerspezifische Merkmale gegenübergestellt. In Abschnitt
6.4 wurden allgemeine Suchmuster präsentiert, mit denen XML-Bibliotheken erkannt
werden können.
7.2. Ergebnisse & Fazit
Diese Arbeit hat gezeigt, dass es durchaus möglich ist, Fingerprinting von XMLBibliotheken durch Storage-Seitenkanäle durchzuführen. Es konnten Merkmale herausgearbeitet werden, an denen die getesteten XML-Bibliotheken, Xerces und MSXML,
in den jeweiligen Versionen identifiziert werden können. Weiterhin wurden Suchmuster herausgearbeitet. Diese Suchmuster ermöglichen es, dass zu einer gegebenen (Web)Applikation mit XML-Anbindung die benutzte XML-Bibliothek herausgefunden werden
kann.
Abschließend gilt es festzuhalten, dass Seitenkanäle in XML-Bibliotheken existieren
und ausgenutzt werden können. Dies stellt ein Sicherheitsrisiko dar, da ein Angreifer
35
7. Abschluss
gezielt die Version und Hersteller der benutzten XML-Bibliotheken herausfinden kann.
Dieses Wissen ermöglicht es einem Angreifer gezielt Schwachstellen auf Fremdsystemen
auszunutzen.
7.3. Beschränkungen & Ausblick
Bei der Untersuchung wurden weitestgehend Standardeinstellungen verwendet. Im
Falle von Xerces wurden zusätzlich noch Ausgabedokumente mit Prettyprint erzeugt.
Die Untersuchungen wurden auf einem Windows-System durchgeführt (Vergleich Abschnitt 4.1). Daher lässt diese Arbeit zunächst nur Schlüsse über das Verhalten auf dieser
Plattform zu. Auf anderen Plattformen wurden bislang keine Untersuchungen durchgeführt. Weiterhin wurden wohlgeformte Dokumente ohne XML-Deklarationen verwendet.
Es wurden keinerlei XML Schema definiert und demnach auch keine Validität der Dokumente geprüft. Außerdem wurden keinerlei Sonderzeichen für Attribut oder Tag-Namen
verwendet.
Für zukünftige Untersuchungen wäre es interessant, weitere XML-Bibliotheken beziehungsweise weitere Versionen der bereits getesteten XML-Bibliotheken zu untersuchen. Zusätzlich könnten die oben erwähnten bisher ungeprüften Einstellungen verwendet werden. Es könnte beispielsweise getestet werden, wie eine MSXML-Bibliothek ein
Dokument ausgibt, in dem die XML-Version auf 1.1 festgelegt wurde. In den bisherigen
Untersuchungen wurde ein Test durchgeführt, bei dem eine Vielzahl von gleichartigen
Tags geparst wurden (Vergleich Abschnitt 3.3 - massTest). Ein vergleichbarer Test könnte auch für Attribute durchgeführt werden. Ebenso interessant wäre das Verhalten der
Bibliotheken bei nicht-wohlgeformten Dokumenten.
Neben diesen Tests wäre es außerdem eine Idee, ein Programm zu schreiben, welches
die Ausgabedokumente von XML-Bibliotheken von Eigenarten säubert. Dieses würde
ein gegebenes Ausgabedokument der jeweiligen XML-Bibliothek einlesen und daraufhin Veränderungen an dem Dokument vornehmen. Diese Veränderungen könnten sich
dann beispielsweise auf die Reihenfolge von Tags und Attributen beziehen. Es könnten
aber auch die Kodierung der verwendeten Zeichen oder die Formatierung der Elemente
verändert werden.
Ein solches Programm würde Storage-Seitenkanäle in XML-Bibliotheken und damit
verbundenes Fingerprinting weitestgehend unterbinden.
36
Literaturverzeichnis
[1] Apple. Apple - Mac OS X Snow Leopard. http://www.apple.com/de/macosx/.
[Zuletzt geprüft: 22.05.2011 - 12:17].
[2] Michael Büchner. XML- und XSL-Prozessoren und deren Parser. 2010.
[3] Tim Bray, Jean Paoli, Eve Maler, François Yergeau, and C. M. Sperberg-McQueen.
Extensible markup language (XML) 1.0 (fifth edition). W3C recommendation,
W3C, November 2008. http://www.w3.org/TR/2008/REC-xml-20081126/.
[4] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein. Introduction to Algorithms. The MIT Press, New York, 2001.
[5] Don Ho. Notepad++. http://notepad-plus-plus.org/. [Zuletzt geprüft: 04.05.2011 18:45].
[6] Rael Dornfest and Kevin Hemenway. Mac OS X hacks - 100 industrial-strength tips
and tools. O’Reilly, 2003.
[7] Mary F. Fernández, Daniela Florescu, Scott Boag, Jonathan Robie, Don Chamberlin, and Jérôme Siméon.
XQuery 1.0: An XML query language (second edition).
W3C proposed edited recommendation, W3C, April 2009.
http://www.w3.org/TR/2009/PER-xquery-20090421/.
[8] Felix C. Freiling and Sebastian Schinzel. Detecting Hidden Storage Side Channel
Vulnerabilities in Networked Applications. IFIP SEC2011. 2011.
[9] Google. Google Chrome - der schnelle, sichere Browser | Kostenloser Download.
http://www.google.de/chrome/. [Zuletzt geprüft: 22.05.2011 - 18:09].
[10] Elliote Rusty Harold and W. Scott Means. XML in a nutshell. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2002.
[11] T. Hauser. XML-Standards : schnell+kompakt. entwickler.press, 2nd edition, 2010.
[12] Andrew Hintz. Fingerprinting websites using traffic analysis. In Roger Dingledine
and Paul Syverson, editors, Privacy Enhancing Technologies, volume 2482 of Lecture
Notes in Computer Science, pages 229–233. Springer Berlin / Heidelberg, 2003.
37
LITERATURVERZEICHNIS
[13] John Ibbotson. SOAP version 1.2 usage scenarios. W3C note, W3C, July 2003.
http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730.
[14] Dean Jackson and Craig Northway.
Scalable vector graphics (SVG) full
1.2 specification.
WD not longer in development, W3C, April 2005.
http://www.w3.org/TR/2005/WD-SVG12-20050413/.
[15] Jan Fiala.
PSPad – der ultimative Editor für Softwareentwickler.
http://www.pspad.com/de/. [Zuletzt geprüft: 22.05.2011 - 16:41].
[16] Linux Foundation. The Linux Foundation. http://www.linuxfoundation.org/. [Zuletzt geprüft: 22.05.2011 - 12:17].
[17] Gordon Lyon. Das Erkennen von Betriebssystemen mittels TCP/IP Stack FingerPrinting. http://goo.gl/Ynziw. 1999.
[18] Gordon Lyon.
TCP/IP Fingerprinting Methods Supported by Nmap.
http://nmap.org/book/osdetect.html. [Zuletzt geprüft: 29.05.2011 - 16:04].
[19] Eve Maler, John Cowan, Jean Paoli, François Yergeau, Tim Bray, and C. M.
Sperberg-McQueen. Extensible markup language (XML) 1.1 (second edition). W3C
recommendation, W3C, August 2006. http://www.w3.org/TR/2006/REC-xml1120060816.
[20] Eve Maler, Jean Paoli, C. M. Sperberg-McQueen, François Yergeau, and Tim Bray.
Extensible markup language (XML) 1.0 (third edition). first edition of a recommendation, W3C, February 2004. http://www.w3.org/TR/2004/REC-xml-20040204.
[21] Microsoft. Windows Home: Windows 7 Features And Tours, Windows Downloads And More. http://www.microsoft.com/germany/windows/. [Zuletzt geprüft:
22.05.2011 - 12:17].
[22] Microsoft. Visual Studio 2010 Startseite. http://www.microsoft.com/germany/visualstudio/.
[Zuletzt geprüft: 22.05.2011 - 16:56].
[23] Microsoft.
MSXML SDK Overview.
http://msdn.microsoft.com/enus/library/ms760399.aspx. [Zuletzt geprüft: 30.05.2011 - 00:40].
[24] Microsoft.
Versionsliste zum Microsoft XML Parser (MSXML).
http://support.microsoft.com/kb/269238. [Zuletzt geprüft: 30.05.2011 - 00:40].
[25] Microsoft Corporation.
Internet Explorer 9 - Das Internet neu erleben.
http://www.internet-explorer9.de/. [Zuletzt geprüft: 22.04.2011 - 21:20].
[26] NEXT-Soft. nextsoft.de: NEXT-Soft Online. http://www.nextsoft.de/. [Zuletzt
geprüft: 30.05.2011 - 18:51].
38
[27] John O’Donnell. An Evaluation of XML Associated Vulnerabilities in the XercesC++ Parser. http://hdl.handle.net/2262/856. 2005.
[28] David Peterson, Shudi (Sandy) Gao, Paul V. Biron, Ashok Malhotra, Henry S.
Thompson, Ashok Malhotra, and C. M. Sperberg-McQueen. W3C xml schema
definition language (XSD) 1.1 part 2: Datatypes. Last call WD, W3C, December
2009. http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/.
[29] Isabell Schmitt. Timing-Seitenkanäle in Web-Anwendungen - Angriffe und Gegenmaßnahmen. Konferenzseminar ÏT Sicherheit 2010"der Universität Mannheim.
2010.
[30] T. J. Sebestyen. XML. Franzis Verlag GmbH, 1st edition, 2004.
[31] Secunia ApS. Microsoft XML Core Services Invalid HTTP Response Handling
Vulnerability. http://secunia.com/advisories/40893/. [Zuletzt geprüft: 28.05.2011 17:14].
[32] C. M. Sperberg-McQueen, Henry S. Thompson, Murray Maloney, Henry S. Thompson, David Beech, Noah Mendelsohn, and Shudi (Sandy) Gao. W3C xml schema
definition language (XSD) 1.1 part 1: Structures. Last call WD, W3C, December
2009. http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/.
[33] Johnny Stenback and Andy Heninger. Document object model (DOM) level 3 load and save specification. W3C recommendation, W3C, April 2004.
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407.
[34] The Apache Software Foundation.
The Apache
http://xerces.apache.org. [Zuletzt geprüft: 25.05.2011 - 15:10].
Xerces
Project.
[35] The
Apache
Software
Foundation.
Xerces
Java
http://xerces.apache.org/xerces-j/. [Zuletzt geprüft: 25.05.2011 - 15:10].
Parser.
[36] The Eclipse Foundation. Eclipse - The Eclipse Foundation open source community
website. http://www.eclipse.org/. [Zuletzt geprüft: 22.05.2011 - 16:56].
[37] The Internet Engineering Task Force (IETF)). UTF-8, a transformation format of
ISO 10646. http://tools.ietf.org/html/rfc3629. [Zuletzt geprüft: 20.05.2011 - 17:40].
[38] Tim Bray and Jean Paoli and Eve Maler and François Yergeau and C. M. SperbergMcQueen. XML in 10 points. http://www.w3c.de/Misc/XML-in-10-points.html.
[Zuletzt geprüft: 19.04.2011 - 18:43].
[39] World Wide Web Consortium (W3C). XML Core Working Group Public Page.
http://www.w3.org/XML/Core/. [Zuletzt geprüft: 27.04.2011 - 18:53].
39
[40] Ted Wugofski, Peter Stark, Masayasu Ishikawa, Mark Baker, Toshihiko Yamakami,
and Shin’ichi Matsui. XHTMLTM basic 1.1. W3C recommendation, W3C, July
2008. http://www.w3.org/TR/2008/REC-xhtml-basic-20080729.
40
A. Anhang
Die Quellcodes, wie auch die in Kapitel 2.3 beschriebenen XML-Bibliotheken, sind auf
dem beiliegenden Datenträger hinterlegt.
41

Fingerprinting of XML Libraries through Storage Side Channel

Transcription

Similar documents

ZUR SPRACHLICHEN INTEGRATION DER ENGLISCHEN

Mensch und Gesellschaft in Oshii Mamorus Ghost in the Shell

news - Druckmarkt

HTML und Verarbeitung, XML - AG Netzbasierte Informationssysteme

XSLT, XSL-FO Transformieren und Formatieren Übersicht zu XSL