XML Spoofing Resistant Electronic Signature (XSpRES)

Transkript

1 Danksagung XML Spoofing Resistant Electronic Signature (XSpRES) Sichere Implementierung für XML Signature 1

2 Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Tel.: Internet: Bundesamt für Sicherheit in der Informationstechnik 2012

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Motivation Voraussetzungen und Rahmenbedingungen Anwendungsfall SOAP-Nachrichten Anforderungen an die Applikationslogik/Datenverarbeitung Anforderungen an das Datenformat der signierten Nachrichten Funktionale Anforderungen Angreifermodell und Angriffsszenarien XSpRES Architektur Elementare Sicherheitsmechanismen von XSpRES FastXPath-basierte Positionsangabe in der SOAP-Nachricht Schutz gegen namespace-basierte Wrappingangriffe XSpRES-Signaturvorverarbeitung DoS-Detektor Schema Validator Referenz Verifikation Präfix Transformator Policy Validierung Nicht abgedeckte Signaturvarianten SAML Assertions Externe Referenzen Prototypische Implementierung Installation und Verwendung Fallstudien Demonstrator Resümee Referenzen...23 Bundesamt für Sicherheit in der Informationstechnik 3

4 Inhaltsverzeichnis Abbildungsverzeichnis Abbildung 1: Signierte SOAP-Nachricht (nur das Body-Element ist signiert)...5 Abbildung 2: Signierte SOAP-Nachricht, die via XSW manipuliert wurde...6 Abbildung 3: Angreifermodell...9 Abbildung 4: Signaturerzeugungsprozess mit XSpRES-Vorverarbeitung...11 Abbildung 5: Signaturverifikation mit XSpRES-Vorverarbeitung...11 Abbildung 6: Verschachtelte SAML-Assertion...18 Abbildung 7: XSpRES Integration mittels Gateways...21 Abbildung 8: XSpRES Demonstrator-Client auf Basis von soapui Bundesamt für Sicherheit in der Informationstechnik

5 Motivation 1 1 Motivation Einer der zentralen sicherheitsspezifischen Standards im Kontext von Service-orientierten Architekturen (SOA) und Webservices ist XML Digital Signature (XmlDSig) [XML-DSig]. XmlDSig erlaubt es, XML-Dokumente sowie Teile davon mit einer elektronischen Signatur zu versehen. Hierdurch soll das Sicherheitsziel der Integrität gewährleistet werden. XmlDSig ist sehr stark verbreitet und in vielen Produkten integriert sowohl im kommerziellen Umfeld als auch im Bereich der freien Software. Die Spezifikation von XmlDSig ist allerdings von einigen Schwachstellen betroffen, die im Entwurf des Standards selbst liegen. Hier wurden verschiedene Angriffsszenarien nicht berücksichtigt, sodass Angriffe wie z.b. der sogenannte XML Signature Wrapping (XSW) Angriff möglich sind. Doch nicht nur in der Spezifikation selbst finden sich Schwachstellen. Insbesondere die hohen Freiheitsgrade der Spezifikation erschweren es zudem, dass darauf aufbauende Implementierungen sicher sind. Dies gilt sowohl für Implementierungen des XmlDSig-Standards selbst als auch für Sicherheitssysteme, die auf XmlDSig beruhen. Die besondere Relevanz des XSW-Angriffs ist in der jüngsten Vergangenheit durch erfolgreich durchgeführte Angriffe auf Cloud-Infrastrukturen aufgezeigt worden. Dabei wurden sowohl quelloffene Systeme als auch kommerzielle Plattformen von namenhaften Diensteanbietern kompromittiert. Durch diese Forschungsarbeiten wurde nachgewiesen, dass es sich beim XSW- Angriff nicht um ein ausschließlich theoretisches Konstrukt handelt, dass keine signifikanten Gefährdungen impliziert. Die Grundproblematik und Quelle der XSW-Angriffe liegt im Mechanismus begründet, wie die signierten Teile im XML-Dokument und die entsprechende Signatur selbst miteinerander verknüpft sind. XmlDSig sieht hierfür einen Referenzierungsmechanismus vor, worüber die Verknüpfung hergestellt wird. In der Praxis wird hierfür de-facto ausschließlich ein Verfahren verwendet, dass die Verknüpfung über Identifizierer (ID) spezifiziert, was in der nachfolgenden Abbildung 1 anhand einer signierten SOAP-Nachricht veranschaulicht wird. Abbildung 1: Signierte SOAP-Nachricht (nur das Body-Element ist signiert) In Abbildung 1 wird eine SOAP-Nachricht dargestellt, die eine Signatur über das Body-Element beinhaltet. Die Signatur ist gemäß dem Sicherheitsstandard für SOAP-Nachrichten WS-Security im Signature-Element abgelegt, das sich im SOAP-Header befindet. WS-Security beruht auf XmlDSig und spezifiziert, wie eine XML-Signatur in eine SOAP-Nachricht einzubringen ist. Es handelt sich Bundesamt für Sicherheit in der Informationstechnik 5

6 1 Motivation hierbei im Grunde um eine XML-Signatur gemäß des XmlDSig-Standards mit einigen Spezifika in Bezug auf die konkrete SOAP-Dokumentstruktur. Dass die Signatur über das Body-Element erzeugt wurde, wird aus der Referenz ersichtlich. Diese verweist auf ein Element, dass das ID-Attribut mit dem Wert body trägt. Dies gilt genau für das Body-Element. Es könnte aber auch für jedes andere Element gelten und insbesondere ist über diese Referenzierungsart nicht zuverlässig verankert, wo sich das signierte Element befindet. Ein XSW- Angriff kann dies nun ausnutzen. Hierzu wird das ursprüngliche Body-Element verschoben und durch ein betrügerisches Body-Element ersetzt, wie es in Abbildung 2 an der zuvor dargestellten Beispielnachricht verdeutlicht wird. Abbildung 2: Signierte SOAP-Nachricht, die via XSW manipuliert wurde Wie aus Abbildung 2 ersichtlich wird, ist der ursprüngliche SOAP-Body noch in der Nachricht enthalten. Er befindet sich jetzt allerdings an einer völlig anderen Position im XML-Dokument. Der SOAP-Body wurde vom Angreifer in den SOAP-Header verschoben und dort in ein neu erzeugtes Element namens Wrapper eingefügt. Dies ist möglich, da die Datendefinition von SOAP- Nachrichten (das SOAP-Schema) beliebige Elemente im SOAP-Header erlaubt. Dies ist aus Gründen der flexiblen Erweiterung von SOAP-Nachrichten so spezifiziert worden und wird an dieser Stelle dankend für den Angriff aufgegriffen. Die Wirksamkeit des Angriffs kommt aber erst durch die Referenzierung zur vollen Entfaltung. Die Referenz auf das verschobene, aber immer noch unversehrte Body-Element ist weiter gültig. Die Signaturverifikation gemäß des XmlDSig bzw. WS-Security Standards wird diese als gültig verifizieren. Die darauf folgende Verarbeitung der SOAP-Nachricht wird auf dem vom Angreifer eingefügten Body arbeiten und eine komplett unbeabsichtigte Aktion auf der Serverseite auslösen. Hieraus wird zudem deutlich, dass nicht nur die Referenzierungsart in die XSW-Problematik mit einspielt, sondern auch die entkoppelte Sicht der verschiedenen Verarbeitungskomponenten auf die Daten eine gewichtige Rolle dabei einnimmt. Das dargestellte Beispiel zur Erläuterung von XSW-Angriffen ist nur eine Art, diesen Angriffstyp durchzuführen. Im Laufe der letzten Jahre sind eine ganze Reihe von Varianten entdeckt worden, die weitere Schwachstellen in den Spezifikationen und Implementierungen zur Konstruktion von XSW-Angriffen ausnutzen. Im Rahmen des Projekts XML Spoofing Resistant Electronic Signature (XSpRES) wurde eine sichere Variante von XmlDSig zur Anwendung auf SOAP-Nachrichten entwickelt, welche nahezu 6 Bundesamt für Sicherheit in der Informationstechnik

7 Motivation 1 alle Vorzüge und die Flexibilität des existierenden Standards beibehält und gleichzeitig gegen die bekannten XSW-Schwachstellen abgesichert ist. Bundesamt für Sicherheit in der Informationstechnik 7

8 2 Voraussetzungen und Rahmenbedingungen 2 Voraussetzungen und Rahmenbedingungen In diesem Kapitel werden die Rahmenbedingungen, Anforderungen und Grenzen festgehalten, die den Funktionsumfang und die Ausgestaltung der Referenzimplementierung von XSpRES vorgeben. 2.1 Anwendungsfall SOAP-Nachrichten Prinzipiell sind alle XML Anwendungen von XSW-Angriffen betroffen. Besondere Auswirkungen hat XSW aktuell in verteilten Anwendungen gezeigt, die auf den SOA-Prinzipien aufbauen und insbesondere SOAP-basierte Webservices als technische Grundlage verwenden. Die nachfolgenden Betrachtungen beziehen sich daher speziell auf derartige Systeme. Das Anwendungsszenario beschreibt eine übertragene Nachricht, bei der sich die Position der signierten Elemente in Bezug auf die Dokumentenwurzel nicht ändert. Das Standardbeispiel hierzu sind signierte SOAP-Nachrichten, aber auch eine signierte SAML Authentication Response fällt auch wenn sie über eine REST-basierte Schnittstelle übertragen wird in diese Kategorie. Es werden daher der Verständlichkeit halber im Folgenden die Datensätze immer als SOAP- Nachricht bezeichnet. Einsatzgebiete von XML Signature, die nicht in diese Kategorie fallen, sind unter Abschnitt 6 zusammengefasst und nicht Gegenstand der Implementierung. 2.2 Anforderungen an die Applikationslogik/Datenverarbeitung Ursache für die Anfälligkeit durch XSW-Angriffe sind unterschiedliche Datenverarbeitungsmechanismen in der Signaturprüfungskomponente und in der Applikationslogik. Die in diesem Konzept etablierten Gegenmaßnahmen zielen darauf ab, diesen Unterschied durch Modifikation der Signaturprüfungskomponente zu beseitigen. Dazu muss jedoch bekannt sein, wie die Datenverarbeitung in der Applikationslogik funktioniert. Da diese Applikationslogik aber in XSpRES nicht fixiert ist, müssen Annahmen getroffen werden. Diese sind die Folgenden: Die Applikationslogik verarbeitet die Daten gemäß einem vorgegebenen Schema: Es wird vorausgesetzt, dass die Applikationslogik, die eine empfangene Nachricht nach erfolgreicher Signaturprüfung weiterverarbeitet, die Schema-Konformität dieser Nachricht überprüft. Wichtige Datenelemente dürfen nur dann verarbeitet werden, wenn sie an der richtigen Stelle im Dokumentenbaum stehen. So muss z.b. der SOAP Body immer unter dem Pfad /Envelope/Body[1] zu finden sein. Eindeutigkeit von ID-Attributen: Die Applikationslogik muss die Datenverarbeitung mit einer Fehlermeldung abbrechen, falls es mehrere identische ID-Attribute im Dokument gibt. 2.3 Anforderungen an das Datenformat der signierten Nachrichten Verbot von XPointer: Im URI-Attribut des Reference-Elements darf kein XPointer verwendet werden. Verbot externer Referenzen: Alle signierten Elemente müssen Bestandteile desselben DOM- Baumes sein. Verbot von XML Entities: Im signierten Dokument dürfen keine XML Entities vorkommen. 8 Bundesamt für Sicherheit in der Informationstechnik

9 Voraussetzungen und Rahmenbedingungen Funktionale Anforderungen XSpRES berücksichtigt die folgenden aktuellen Spezifikationen: Extensible Markup Language [XML] Canonical XML [XML-C14N] Exclusive XML Canonicalization [XML-EXC] XML-Signature Syntax and Processing [XML-DSig] XML Path Language [XPath] XML-Signature XPath Filter 2.0 [XPath-Filter2] Namespaces in XML [XML-NS] XML Schema [XML-Schema] Basic security profile [BSP] SOAP [SOAP] Web Services Policy [WS-Policy] Web Services Security Policy [WS-SecurityPolicy] Web Services Description Language [WSDL 1.1] Die Sicherheitsmechanismen für XML Signature werden für den Signaturtyp Detached Signatures realisiert. 2.5 Angreifermodell und Angriffsszenarien Das Angreifermodell berücksichtigt ausschließlich Angriffe auf über das Netzwerk übertragene Daten (siehe Abbildung 3). Diese können vom Angreifer beliebig modifiziert werden. Als vertrauenswürdig werden alle Daten (z.b. XML Schemata, WS-Policy-Dateien) angesehen, die lokal konfiguriert werden. Abbildung 3: Angreifermodell Vorkehrungen gegen XSW-Angriffe werden durch verbesserte Sicherheitsmaßnahmen in der Signaturerzeugungs- und der Signaturverifikationskomponente realisiert. Diese sind in den Kapiteln 3, 4 und 5 näher beschrieben. Der in [CIXSE] beschriebene Angriff wird dadurch abgefangen, dass die Überprüfung der Signatur über das <SignedInfo>-Element vor der Überprüfung der Hashwerte in den <Reference>- Elementen durchgeführt wird. Bundesamt für Sicherheit in der Informationstechnik 9

10 2 Voraussetzungen und Rahmenbedingungen Manipulationen der Semantik der Elemente <KeyInfo> oder <RetrievalMethod> werden durch Einschränkung der hier möglichen Varianten abgefangen. DoS-Angriffe werden schwerpunktmäßig im StAX-Parser abgefangen (siehe Kapitel 5.1). 10 Bundesamt für Sicherheit in der Informationstechnik

11 XSpRES Architektur 3 3 XSpRES Architektur Um die geforderte Konformität zum XML Signature Standard zu wahren wurde eine Architektur erarbeitet, die auf dem Prinzip der Vorverarbeitung (Preprocessing) beruht. Sowohl der Signaturerzeugungsprozess (siehe Abbildung 4) als auch der Signaturverifikationprozess (siehe Abbildung 7) werden vor der eigentlichen Erzeugung bzw. Verifikation der XML Signatur durch Vorverarbeitungsschritte erweitert, die bestimmte Verifikationen bzw. Transformationen vornehmen. Abbildung 4: Signaturerzeugungsprozess mit XSpRES-Vorverarbeitung Abbildung 4 zeigt die Verarbeitungskette zur Signaturerzeugung. Sie ist durch vorangestellte XSpRES-Komponenten angereichert, die spezifische Vorverarbeitungsaufgaben wahrnehmen. Die Maßnahmen bei der Signaturerstellung sind so konzipiert, dass sie für jede Signaturverifikationskomponente wirksam sind, also auch für diejenigen von Drittanbietern. Abbildung 5: Signaturverifikation mit XSpRES-Vorverarbeitung Abbildung 5 zeigt die Verarbeitungskette zur Signaturverifikation. Diese ist ebenfalls durch XSpRES-Komponenten erweitert worden, die spezifische Vorverarbeitungen durchführen. Bundesamt für Sicherheit in der Informationstechnik 11

12 4 Elementare Sicherheitsmechanismen von XSpRES 4 Elementare Sicherheitsmechanismen von XSpRES 4.1 FastXPath-basierte Positionsangabe in der SOAP-Nachricht Bei der XPath-Referenzierung innerhalb einer XML Signatur werden grundsätzlich zwei Standards verwendet: XPath (Filter) 1.0 [XPath] und XPath Filter 2.0 [XPath-Filter2]. Diese beiden Standards erlauben die Anwendung der vollen XPath-Grammatik, was die Referenz-Suche innerhalb des XML-Dokuments anfällig für bestimmte Angriffe macht. Darüber hinaus ist die volle XPath- Grammatik nicht direkt mit einem Streaming-basierten XML Parser auswertbar, da sie auch Rückwärtsachsen und ODER-Verknüpfungen erlaubt. Die Position der signierten Daten im Dokument wird deswegen durch einen FastXPath-Datensatz bezeichnet. Dieser Datensatz wird standardkonform nach XPath Filter 2.0 eingebettet. Dadurch wird es ermöglicht, dass eine XSpRES-konforme Implementierung ihn nach FastXPath auswerten kann, und eine Standardimplementierung nach XPath Filter 2.0 auswerten kann. XPath (1.0) wird bei der Signaturerstellung nicht explizit unterstützt. FastXPath [FastXPath] ist eine Teilmenge von XPath, die nur die Vorwärtsachsen erlaubt. Darüber hinaus sind bei FastXPath keine ODER-Verknüpfungen in Booleschen Ausdrücken erlaubt. Nach der FastXPath-Grammatik erstellte Ausdrücke sind daher mit einem Streaming-basierten Parser auswertbar. Um XSW-Angriffe zu verhindern, wird zusätzlich für jedes Element dessen Position auf der bestimmten Baum-Ebene definiert. Dies verhindert das Verschieben (Verdoppeln) der signierten Teile und die Signatur-Validierungs-Komponente kann die Elemente auf derselben Position verifizieren, auf der sie signiert wurden. Eine angepasste FastXPath-Grammatik ist wie folgt definiert: FastXPath ::= / RelativeFastXPath RelativeFastXPath ::= Step RelativeFastXPath / Step Step ::= QName PredicatePosition PredicatePosition ::= Position Predicate? Predicate Position? Position ::= [ [1-9][0-9]* ] Predicate ::= [ PredicateExpr ] PredicateExpr ::= PredicateStep PredicateExpr and PredicateStep PredicateStep QName = Literal Literal ::= " [ˆ"]* " " " [ˆ ]* " " Beispiele der korrekten FastXPath-Ausdrücke werden damit: /Envelope[1]/Body[1]/function[1] oder /Envelope[1]/Header[1]/Security[1][@role="next"] Folgende XPath-Ausdrücke werden nicht als FastXPath-konform gekennzeichnet: //Body[1] : ist ein relativer XPath Ausdruck und startet nicht im Dokument-Root /Envelope[1]/Body/Function : beinhaltet keine Positions-Prädikate bei dem Body- und Function-Element 12 Bundesamt für Sicherheit in der Informationstechnik

13 Elementare Sicherheitsmechanismen von XSpRES 4 /Envelope[1]/Header[1]/Security[1][@role="next" : innerhalb des Prädikats befindet sich eine ODER-Verknüpfung, die bei der Streamingbasierten Bearbeitung nicht auswertbar ist. Um die Nutzung der FastXPath-Grammatik auf der Signatur-Erstellungs-Seite zu automatisieren, wird eine Komponente entwickelt, die die XPath-Ausdrücke aus der WS-Security Policy bei der Signatur-Erstellung in gleichwertige FastXPath-Ausdrücke umschreibt. 4.2 Schutz gegen namespace-basierte Wrappingangriffe Wie in [SWS09] ausgeführt, existiert bei der Verwendung von XPath zur Selektion der signaturrelevanten Dokumentteile eine Schwachstelle in der derzeit geltenden Kanonisierung von Namespace-Deklarationen (vgl. [XML-EXC]). Die in der Praxis häufig eingesetzte Technik der Verwendung von Namespace-Präfixen innerhalb des selektierenden XPath-Ausdruckes kann selbst bei ideal gewähltem XPath-Ausdruck für eine erfolgreiche Signature-Wrapping-Attacke ausgenutzt werden. Das Kernproblem hierbei besteht in der Tatsache, dass die aktuell gültige Version der W3C-Empfehlung Exclusive XML Canonicalization Version 1.0 bestimmte Namespace- Deklarationen im Signaturkontext falsch verarbeitet. Da diese Spezifikation derzeit den de-facto Standard zur Kanonisierung von XML-Dokumenten darstellt, ergibt sich daraus eine umfassende Angreifbarkeit derartig arbeitender Systeme. Als Lösung für dieses Problem wurde in der Arbeitsgruppe XML Security des W3C vorgeschlagen, den XPath-Ausdruck selbst nach verwendeten Namespace-Präfixen zu durchsuchen, und diese Präfixe bei der Kanonisierung einzubeziehen. Nach wissenschaftlichen Gesichtspunkten ist diese Lösung zwar potentiell umsetzbar, aber sehr anfällig für eine fehlerhafte Implementierung. Dementsprechend wird bei XSpRES ein alternativer Ansatz verfolgt, der den besonderen Eigenheiten von XPath-Ausdrücken im Kontext von XML-Signaturen Rechnung trägt. Um der zugrundeliegenden Kernproblematik der Verwendung von Namespace-Präfixen in XPath- Ausdrücken beizukommen, wird eine neuartige Transformationskomponente entwickelt, die XPath- Ausdrücke mit Namespace-Präfixen in eine semantisch 100 % äquivalente Darstellung ohne Namespace-Präfixe überführt. Konkret wird ein XPath der Form prefix:element mit der Bindung xmlns:prefix=" in eine erweiterte XPath-Syntax der Form *[localname()="element" and namespace-uri()=" überführt. Dadurch ist die semantisch relevante Bindung des Elementes element an den Namespace garantiert, auch wenn sich die Bindung des Präfix prefix kontextbedingt ändern sollte. Entsprechend wird durch derart transformierte XPath-Ausdrücke eine exakt identische Selektion vorgenommen, allerdings ohne die Möglichkeit eines Angriffes über die Namespace-Injection-Technik aus [SWS09]. In XSpRES wird ein entsprechendes Transformationsmodul implementiert und bei der Signaturerzeugung sowie bei der WS-SecurityPolicy-Erstellung eingesetzt, um im betreffenden Kontext existente XPath-Ausdrücke analog obigem Beispiel umzuwandeln. Im Fall der Signaturerzeugung bedeutet dies, dass nach erfolgreicher Validation des verwendeten XPath- Ausdruckes (siehe vorigen Abschnitt 4.1) und vor Erzeugung der für die Signaturerstellung relevanten Hashwert-Berechnungen sämtliche XPath-Ausdrücke aus sämtlichen XPath-Filter2- Transformationen der XML-Signatur mittels der zu implementierenden Komponente in eine Präfixfreie Version umgewandelt werden. Analog werden sämtliche zur Selektion eingesetzten XPath- Ausdrücke in allen Sicherheitsregelwerken auf Basis des WS-SecurityPolicy-Standards ebenfalls in ihre präfixfreie Äquivalentversion transformiert, um auch hier eine größtmögliche Schutzwirkung gegen potentielle zukünftige Namespace-basierte Angriffstechniken zu garantieren. Bundesamt für Sicherheit in der Informationstechnik 13

14 5 XSpRES-Signaturvorverarbeitung 5 XSpRES-Signaturvorverarbeitung Die in den Vorverarbeitungsketten dargestellten XSpRES-Komponenten (siehe Abbildung 4 und Abbildung 7) werden in diesem Kapitel detailliert beschrieben. 5.1 DoS-Detektor Der erste Vorverarbeitungsschritt auf der Serverseite führt für eingehende Nachrichten eine einfache Denial of Service (DoS) Angriffserkennung durch. Dazu wird die Nachricht mithilfe eines StAX Parsers elementweise eingelesen und folgende Parameter ausgewertet: Die Gesamtanzahl der Elemente in der Nachricht. Die maximale Breite eines Zweiges der Nachricht. Die maximale Tiefe eines Zweiges der Nachricht. Die maximale Anzahl an vorkommenden Transformationen. Jede Transformation wird zusätzlich mit einer Blacklist verglichen. Stimmen diese überein, wird die eingehende Nachricht umgehend verworfen. Alle ID-Attribute werden zusätzlich ermittelt. Sollte der Wert eines ID-Attributes mehr als einmal auftreten, wird die Nachricht ebenfalls verworfen. Sollten einer diese Zähler einen bestimmten Schwellwert überschreiten, wird die Verarbeitung abgebrochen und die Nachricht wird vom Server verworfen. Die Schwellwerte sind konfigurierbar und können damit den entsprechenden Anwendungsgegebenheiten angepasst werden. Da der DoS- Detektor, wie in Kapitel beschrieben, als Axis2-Modul implementiert ist, werden die Konfigurationseinstellungen in der für Axis2-Module vorgesehenen XML-Konfigurationsdatei getroffen. Diese befindet sich im buildfiles/meta-inf/ Ordner der XSpRES-Distribution und heißt module.xml. Diese Komponente stellt somit sicher, dass keine Endlos-Nachrichten empfangen werden, die den gesamten Hauptspeicher des Servers vereinnahmen und diesen damit zum Erliegen bringen. 5.2 Schema Validator Grundsätzlich funktioniert die XSpRES Schema Validator Komponente auf Server-Seite wie jeder Standard Schema Validator. Sie liest eine gegebene, lokal verfügbare Schema Definitionsdatei ein und überprüft dann, ob die eingehende Nachricht diesem Schema folgt. Allerdings enthalten alle Versionen von SOAP-Schemata eine Schwachstelle, die es einem Angreifer ermöglicht, eine Nachricht leicht mit selbst definierten Elementen zu füllen, ohne dabei das Schema zu verletzen. Möglich wird dies durch die Verwendung von xs:any als erlaubtes Kind, wie im folgenden Beispiel anhand eines Ausschnitts aus der SOAP-Schemadatei aufgezeigt wird: <xs:element name="header" type="tns:header"/> <xs:complextype name="header"> <xs:sequence> <xs:any namespace="##other" minoccurs="0" maxoccurs="unbounded" processcontents="lax"/> </xs:sequence> <xs:anyattribute namespace="##other" processcontents="lax"/> </xs:complextype> 14 Bundesamt für Sicherheit in der Informationstechnik

15 XSpRES-Signaturvorverarbeitung 5 Zusätzlich bietet dass Attribut processcontents="lax" die Möglichkeit, auch Elemente, für die kein Schema verfügbar ist, zu erlauben. XSpRES nutzt sogenannte gehärtete Schemata. Diese wurden manuell erstellt, indem alle Vorkommen von xs:any und processcontents="lax" entfernt wurden. Dies hat zur Folge, dass alle häufig verwendeten SOAP-Zusatzfunktionen direkt in das gehärtete Schema eingebettet werden müssen, da es später nicht mehr erweiterbar ist. So enthält das gehärtete Schema von XSpRES ebenfalls die Schema Definitionen von WS-Security, WS-Utilities, Digital Signature, XPath-Filter2 und WS-Addressing. Die Anzahl der verwendeten und eingebetteten Schemata wurde absichtlich derart restriktiv festgelegt, um die Bearbeitungszeit zur Schema-Validierung möglichst gering zu halten. Die gehärteten Schemata finden sich in der XSpRES-Distribution im Ordner schema. 5.3 Referenz Verifikation Der erste Vorverarbeitungsschritt bei der Signaturerzeugung (siehe Abbildung 4) bzw. der zweite Vorverarbeitungsschritt bei der Signaturverifikation (siehe Fehler: Referenz nicht gefunden) basieren auf der Referenz Verifikation. Grundsätzlich ist die Aufgabe dieser Komponente zu prüfen, ob FastXPath-Ausdrücke zur Referenzierung der von der Signatur eingeschlossenen Dokumententeile verwendet werden. Andere Referenzierungsmechanismen werden nicht akzeptiert, da nur durch die Verwendung von FastXPath-Ausdrücken eine feste Bindung von Signatur und signiertem Inhalt im Dokument sichergestellt werden kann. Ein WS-SecurityPolicy-basiertes Regelwerk, das von der Referenz Verifikation akzeptiert wird, hat z.b. folgende Form: <wsp:policy wsu:id="sigonly" xmlns:wsu=" xmlns:wsp=" <wsp:exactlyone> <wsp:all>... <sp:signedelements xmlns:soapenv=" xmlns:wsse=" xmlns:wsu=" xmlns:sp=" <sp:xpath>/soapenv:envelope[1]/soapenv:body[1]</sp:xpath> <sp:xpath>/soapenv:envelope[1]/soapenv:header[1]/wsse:security[1]/wsu:timestamp[1]</sp:xpath> </sp:signedelements> </wsp:all> </wsp:exactlyone> </wsp:policy> Der oben angegebene Ausschnitt einer WS-SecurityPolicy ist aus Gründen der besseren Lesbarkeit auf die hier wesentlichen Aspekte gestutzt worden. Das Augenmerk soll insbesondere auf die hervorgehobenen XPath-Elemente gerichtet werden, da der FastXPath Validator die WS- SecurityPolicy genau nach derartigen Einträgen durchsucht. Folgen die Ausdrücke der Kind Elemente des SignedElements Element nicht der FastXPath-Grammatik, bricht der Referenz Validator die Vorverarbeitung ab und unterbindet eine Signaturerzeugung frühzeitig, da diese möglicherweise für XSW-Angriffe anfällig ist. Hier ist zu beachten, dass bei herkömmlichen Implementierungen von WS-Policy eine Umsetzung in eine ID-basierte Referenzierung erlaubt ist, was XSW-Angriffe geradezu herausfordert. Die vollständige Beispiel-Policy liegt der XSpRES- Distribution als Testvektor bei (policy/policy.xsd). Die Funktionalität des Referenz Validators ist in der Klasse xspres.components.fastxpath. FastXPathValidator implementiert. Eine UnitTest-Klasse im gleichen Paket mit dem Namen Bundesamt für Sicherheit in der Informationstechnik 15

16 5 XSpRES-Signaturvorverarbeitung FastXPathValidatorTest dient zum einen zu Testzwecken und zum anderen zeigt diese auch auf, wie die FastXPathValidator-Klasse verwendet wird. Hier ein Beispiel: FastXPathValidator validator = new FastXPathValidator(); boolean isvalid = validator.validate("/envelope[1]/body[1]/function[1]"); Liegt eine Instanz der Klasse vor, kann über die validate()-methode der übergebene String- Parameter auf dessen Konformität zum FastXPath-Sprachumfang geprüft werden. Die Methode liefert einen Wahrheitswert zurück, der via true signalisiert, dass es sich beim Parameter um einen FastXPath-Ausdruck handelt. Anderfalls liefert die Methode false zurück. 5.4 Präfix Transformator Der zweite Vorverarbeitungsschritt bei der Signaturerzeugung (siehe Abbildung 4) bzw. der dritte Vorverarbeitungsschritt bei der Signaturverifikation (siehe Fehler: Referenz nicht gefunden) basiert auf dieser Komponente. Grundsätzlich ist die Aufgabe des sogenannten Präfix Transformators die FastXPath-Ausdrücke, nachdem deren Vorkommen in der Policy durch die Referenz- Verifikationskomponente sichergestellt wurde, zur Referenzierung der von der Signatur eingeschlossenen Dokumentteile in ihre äquivalente präfixfreie Form zu überführen. Hierdurch werden Namespace Injection Angriffe unterbunden. Der Präfix Transformator wandelt dazu jeden Teilausdruck des FastXPath von der Form /präfix:lokalername[1] in die gegen Namespace Injection gesicherte Form /*[local-name()='lokalername' and namespace-uri=' um. Dieser semantisch identische, transformierte FastXPath-Ausdruck enthält nun nicht mehr das ungesicherte Präfix, sondern greift auf dasselbe Element direkt über dessen Namespace-URI zu, ohne dass das Präfix selbst benötigt wird. Es wäre auch möglich gewesen, prinzipiell nur solche präfixfreien FastXPath-Ausdrücke in der WS-SecurityPolicy zu erlauben. Allerdings sollte eine Möglichkeit geschaffen werden, die kompakte Schreibweise für FastXPaths weiterhin zu erlauben, ohne eine Einbuße bei der Sicherheit zu haben. 5.5 Policy Validierung In WS-SecurityPolicy wurde eine FastXPath-Regel eingeführt. Die zwingend mit zu signierenden Elemente werden durch Standard-FastXPath-Ausdrücke in WS-SecurityPolicy abgebildet. Wichtig ist dabei, dass die Semantiken der XPath-Ausdrücke in WS-SecurityPolicy und XPathFilter 2 übereinstimmen. Durch die Policy Validierung wird vereinfacht gesagt sichergestellt, dass bei der eingehenden Nachricht die korrekten Fragmente signiert sind. Eine SOAP-Nachricht, die der Prüfung der Policy Stand halten würde, ist in stark verkürzter Form auf das hier maßgebliche reduziert im Folgenden dargestellt: <soapenv:envelope> <soapenv:header> <wsse:security> <wsu:timestamp> <wsu:created> t20:58:41z</wsu:created> <wsu:expires> t20:59:41z</wsu:expires> </wsu:timestamp> <ds:signature> <ds:signedinfo> 16 Bundesamt für Sicherheit in der Informationstechnik

17 XSpRES-Signaturvorverarbeitung 5 <ds:canonicalizationmethod Algorithm=".../REC-xml-c14n #WithComments"/> <ds:signaturemethod Algorithm=".../xmldsig#rsa-sha1"/> <ds:reference> <ds:transforms> <ds:transform Algorithm=" <XPath Filter="intersect"> /*[local-name()="envelope" and namespace-uri()=" /*[local-name()="body" and namespace-uri()=" </XPath> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>...</ds:signaturevalue> <ds:keyinfo>...</ds:keyinfo> </ds:signature> </wsse:security> </soapenv:header> <soapenv:body>... </soapenv:body> </soapenv:envelope> Die Komponente sucht alle XPath Ausdrücke aus dem Transforms Element der Signatur. Diese werden anschließend mit den Transformierten FastXPath Ausdrücken, die auf der Serverseite analog zur Clientseite erstellt wurden, verglichen. Dazu wird ein simpler paarweiser String- Vergleich durchgeführt. Nur wenn alle transformierten FastXPath Ausdrücke identisch sind, wird mit der Verarbeitung fortgefahren. Andernfalls wird die Nachricht nicht akzeptiert. Wichtig an dieser Stelle ist es zu verstehen, dass für die XPath Ausdrücke in der eingehenden Nachricht kein FastXPath Validator genutzt werden kann, da dort nur die transformierten FastXPath Ausdrücke stehen, welche selbst wiederum nicht der FastXPath-Grammatik folgen. Bundesamt für Sicherheit in der Informationstechnik 17

18 6 Nicht abgedeckte Signaturvarianten 6 Nicht abgedeckte Signaturvarianten Für einige Einsatzgebiete von XML Signature unterscheidet sich die Datenverarbeitung in der Applikationslogik so stark vom Standardfall der signierten Nachrichtenübertragung, dass eine Integration in den Prototypen von XSpRES nicht sinnvoll ist. Hier sind weitere Forschungen und ggf. die Entwicklung eines separaten Lösungsansatzes notwendig. 6.1 SAML Assertions XML Signature spielt als Signaturverfahren für SAML Assertions auch in REST-basierten Szenarien eine große Rolle (z.b. Login für diverse Cloud-Dienste). Die Signatur muss aber, im Gegensatz zum SOAP-basierten Szenarien in WS-Security, auch dann erhalten bleiben, wenn die SAML Assertion beliebig im Dokument verschoben wird. Dies schließt eine Referenzierung über einen absoluten XPath-Ausdruck aus. Weiterhin ist zu beachten, dass in SAML Enveloped Signatures spezifiziert sind. Die ganze Komplexität des Problems kann am folgenden Beispiel erläutert werden. Abbildung 6: Verschachtelte SAML-Assertion In Abbildung 6 ist eine gültige, signierte SAML Assertion in eine zweite Assertion eingefügt. Die zweite Assertion mit der ID 1 ist nicht signiert, kann also von einem Angreifer gefälscht werden und sollte daher von der Applikationslogik ignoriert werden. Welche Assertion aber tatsächlich ausgeführt wird, hängt stark von der jeweiligen Implementierung ab, ebenso wie die genaue Umsetzung der Auflösung der Referenzierung in der XML-Signatur. 6.2 Externe Referenzen Um externe Referenzen aufzulösen, muss das Domain Name System in die Signaturüberprüfung mit einbezogen werden. Angriffe auf DNS (z.b. Dynamic Pharming) sowie Netzwerk-basierte Angriffe können hier zu einer Invalidierung der Signatur führen. 18 Bundesamt für Sicherheit in der Informationstechnik

19 Prototypische Implementierung 7 7 Prototypische Implementierung Zur praktischen Evaluierung von XSpRES wurde die Implementierung in eine konkrete Webservice Umgebung integriert, auf die im Folgenden eingegangen wird. Neben der Analyse und dem Test der Entwicklungen stand zudem das Bereitstellen eines Demonstrators im Fokus, um die Ergebnisse in einer realen Anwendung zeigen zu können sowie Interessierten einen möglichst einfachen Einstieg in das Framework zu ermöglichen. 7.1 Installation und Verwendung Die entwickelten Komponenten können sehr vielfältig verwendet werden. Beim Entwurf wurde Wert darauf gelegt, möglichst ohne Abhängigkeiten von Bibliotheken Dritter auszukommen. Der einfachen Integration der XSpRES-Komponenten in Java-basierte Systeme, seien es beliebige Webservice Frameworks oder andere Anwendungen, die XML-Dokumente verarbeiten, steht somit nichts im Wege. Die entsprechenden Quellen bzw. Klassen können einfach in gängige Entwicklungsumgebungen importiert werden und stehen dort dem Entwicklungsprojekt umgehend bereit. Um die im Rahmen des Projekts erforderlichen Tests und Evaluierungen durchführen zu können, wurde eine derartige Integration in das freie und quelloffene Apache Axis2 Webservice Framework vorgenommen. Auf dieser Grundlage ist zudem eine Gateway-basierte Lösung implementiert worden, mit der auch in heterogenen Systemumgebungen auf die XSpRES-Funktionalitäten zugegriffen werden kann. Beide Verwendungsmuster werden im Folgenden als Fallstudien besprochen. 7.2 Fallstudien Zum besseren Verständnis, wie die implementierten XSpRES-Komponenten verwendet werden können, soll in den folgenden Unterkapiteln anhand von zwei Fallstudien gezeigt werden, wie von XSpRES in den spezifischen Umgebungen Gebrauch gemacht werden kann. Mit der ersten Fallstudie soll anhand des Apache Axis2 Frameworks gezeigt werden, wie sich die XSpRES- Komponenten in ein Java-basiertes Webservice-Framework integrieren lassen. Die zweite Fallstudie behandelt ein Integrationsmuster, das für nicht-java Umgebungen geeignet ist Integration in das Webservice-Framework Apache Axis2 Eine Kurzanleitung zur Integration in das Apache Axis2 Framework befindet sich im Ordner der XSpRES-Distribution unter dem Dateinamen README.txt. Dabei ist grundsätzlich folgendes Vorgehen notwendig: Apache Axis2 von der offiziellen Webseite 1 herunterladen und entpacken. Apache Axis2 Sicherheitmodul Rampart mit derselben Versionsnummer wie Axis2 von der offiziellen Webseite 2 herunterladen. Anschließend alle Dateien aus dem Rampart lib/ Ordner in das Axis2 lib/ Verzeichnis kopieren. Selbes gilbt für den modules/ Ordner. Das Rampart-Modul wird lediglich für die Erstellung und Verifikation der Zeitstempel genutzt Bundesamt für Sicherheit in der Informationstechnik 19

20 7 Prototypische Implementierung In der Konfigurationsdatei axis2.conf im conf/ Verzeichnis müssen die XSpRES Komponenten aktiviert werden: DoS Detection aktivieren (Message Builder) Server als Gateway konfigurieren (Message Receiver) XSpRES-Modul aktivieren (<module ref="xspres"/>) In der Konfigurationsdatei META-INF/services.xml eines jeden Services evtl. vorkommenden <messagereceivers> Einträger deaktivieren Betrieb und Integration in Gateways Die XSpRES-Distribution wurde in Java implementiert. Dabei wurde ausschließlich auf Standard Java-Bibliotheken zurückgegriffen. Hierdurch wird die Verwendung der XSpRES-Distribution erleichtert, da diese ohne große Aufwände in Java-basierte Projekte integriert werden kann. Dennoch besteht eine Einschränkung durch die gewählte Programmier- und Laufzeitumgebung. Diese Grenze kann aber aufgebrochen werden und die XSpRES-Funktionalitäten auch in nicht Java-basierten Umgebungen nutzbar gemacht werden. Die Integration kann mittels Gateways erfolgen, die die Signaturerzeugungsfunktionen und die Signaturverifikationsfunktionen in einem Client- bzw. Server-Gateway kapseln (siehe Abbildung 7). Abbildung 7: XSpRES Integration mittels Gateways Zwischen dem eigentlichen Webservice-Client und dem Anwendungsserver wird jeweils eine weitere Komponente zwischengeschaltet. Das Client-Gateway nimmt die zu signierende Nachricht vom Client entgegen und erstellt mit den XSpRES-Komponenten aus Kapitel 5 eine Signatur. Die Nachricht wird anschließend an das Server-Gateway weitergeleitet, wo sie auf potentielle XSW- Schwachstellen bzw. -Manipulationen untersucht wird. Hier wird die Signatur verifiziert und im Erfolgsfall die vollständige Nachricht an die eigentliche Anwendungslogik zur Verarbeitung weitergereicht. 7.3 Demonstrator Der in der Distribution enthaltene Demonstrator beruht auf dem in Abbildung 7 gezeigten Aufbau. Die folgenden Unterkapitel erläutern, wie sich die einzelnen Komponenten starten lassen und wie sich mit den bereitgestellten Artefakten verschiedene Szenarien durchspielen lassen. In der Distribution findet sich eine äquivalente Beschreibung in kürzerer Form und englischer Sprache (demo/readme.txt). Als Betriebssystem wird eine auf Unix-basierende Umgebung angenommen. Der Demonstrator ist auch auf Microsoft Windows Betriebssystemen verwendbar, hierfür müssen allerdings einige der Skript-Programme und Hilfsmittel zum Start der einzelnen Komponenten entsprechend portiert werden. Der Demonstrator ist so ausgestaltet, dass er mit einem einzelnen Rechnersystem ausgeführt werden kann. Eine vernetzte Infrastruktur ist damit nicht erforderlich. 20 Bundesamt für Sicherheit in der Informationstechnik

21 Prototypische Implementierung WS-Client Der WS-Client wird durch soapui 3 realisiert. Bei soapui handelt es sich um ein frei-verfügbares Werkzeug mit graphischer Benutzerschnittstelle, womit u.a. SOAP-basierte Webservices getestet werden können. Die bereitgestellte Datei demo/1_client/xspres-soapui-project.xml beinhaltet ein soapui-projekt, das verschiedene vorkonfigurierte Nachrichten beinhaltet, die an den Beispiel- Webservice (siehe Kapitel 7.3.4) geschickt werden können. Dieses muss in die Anwendung importiert werden. Die darin enthaltenen Dienste können mit Nachrichten angesprochen werden, die sowohl gültig als auch ungültig definiert wurden. Abbildung 8: XSpRES Demonstrator-Client auf Basis von soapui Der in Abbildung 8 dargestellte Screenshot zeigt die soapui-anwendung mit dem importierten Projekt und der geladenen Hello-Nachricht und der Antwort der Server-Applikation. Das soapui-projekt enthält unter anderem Beispiele, die eine Hello Nachricht an die verschiedenen Endpunkte (Client-Gateway, Server-Gateway, Server-Applikation) senden, um deren Antworten exemplarisch betrachten zu können. Darüber hinaus ist eine Test-Suite enthalten, die jeweils 1000 Nachrichten an das Server-Gateway sendet. Dies wurde zur Performance Evaluierung genutzt XSpRES Client Gateway Das XSpRES Client Gateway liegt für den Demonstrator vorkonfiguriert im Ordner demo/2_clientgateway. Zum Starten des Gateways genügt es, die JAR-Datei von der Java VM ausführen zu lassen. Dies kann in einem Terminal mit dem folgendem Befehl bewerkstelligt werden: java -jar clientgateway.jar Da beim Start einige Konfigurationsdateien und kryptographische Schlüssel eingelesen werden, ist hierbei unbedingt darauf zu achten, dass das aktuelle Arbeitsverzeichnis mit dem 3 Bundesamt für Sicherheit in der Informationstechnik 21

22 7 Prototypische Implementierung Installationsverzeichnis übereinstimmt, also demo/2_clientgateway ist. Das Gateway erzeugt detaillierte Ausgaben in der Konsole, die Aufschluss darüber geben, wie die Verarbeitung stattgefunden hat XSpRES Server Gateway Der XSpRES Server Gateway ist ähnlich ausgestaltet wie der XSpRES Client Gateway. Für den Demonstrator ist dieser im Ordner demo/3_servergateway abgelegt. Die technische Basis des Gateways ist durch das Java-basierte quelloffene und freie Webservice Framework Apache Axis2 gegeben. Dieses muss nicht installiert werden, da sich im genannten Ordner bereits eine Installation von Axis2 befindet, die für den Demonstrator angepasst wurde. Um den Gateway zu starten, wird ein Terminal benötigt, dessen Arbeitsverzeichnis auf demo/3_servergateway gesetzt werden muss. In diesem Verzeichnis kann dann der Gateway mit dem folgenden Befehl gestartet werden: sh axis /bin/axis2server.sh Befindet sich das Terminal bei der Befehlsausführung nicht im Ordner demo/3_servergateway, werden benötigte Konfigurationsartefakte nicht gefunden und der Prozess mit einer entsprechenden Fehlermeldung abgebrochen WS-Dienst Die eigentlichen Dienste sind im Ordner demo/4_serverapplication enthalten. Gestartet werden der Server und die darüber bereitgestellten Dienste durch den Aufruf des Java-Interpreters mit dem Kommando: java -jar serverapplication.jar Auch hier gilt es wieder zu beachten, dass sich das Terminal im Verzeichnis demo/4_serverapplication befindet, um einen reibungslosen Start zu gewährleisten. 22 Bundesamt für Sicherheit in der Informationstechnik

23 Resümee 8 8 Resümee Die fundamentalen Sicherheitsstandards XML Encryption und XML Signature bilden das Rückgrat für viele Anwendungen, die XML-Dokumente verarbeiten. Just diese Standards haben in der jüngsten Vergangenheit allerdings einige Schwächen sowohl in den Spezifikationen als auch in den Implementierungen aufgewiesen. Darunter zählt der sogenannte XML Signature Wrapping (XSW) Angriff zu den gravierendsten Gefährdungen, da mit diesem Angriff nachweislich die Sicherheit von Produkten und Systemen ausgehebelt werden konnte. XSW darf somit nicht mehr als tragbares Restrisiko abgehandelt werden. XSW Angriffe sind reale Bedrohungen, deren Praktikabilität und Schadensausmaß bereits mehrfach im Cloud-Umfeld aufgezeigt wurden. Aktuell bringt XSW SAML-basierte Identitäts- und Access- Managementsysteme (IAM) ins Wanken und macht sicher zukünftig auch nicht vor anderen XML- Dokumenttypen halt. Das BSI hat mit den Projektpartnern Ruhr-Universität Bochum und Fachhochschule Köln das Projekt XML Spoofing Resistant Electronic Signature (XSpRES) umgesetzt und eine Lösung für die XSW-Problematik erarbeitet. Somit ist nun eine erste (prototypische) Implementierung einer sicheren Best-Practice-Variante von XML Signature verfügbar, welche möglichst alle Vorzüge und die Flexibilität des existierenden Standards beibehält und gleichzeitig gegen sämtliche bekannten XSW-Schwachstellen abgesichert ist. Dieses Projekt wird u.a. als Impuls verstanden, durch den die ins Stocken geratene internationale Standardisierung neuen Anschub erfahren soll. Für Java-basierte Webservices liegt nunmehr ein wirksamer Schutz gegen XSW-Angriffe in Form einer Software-Bibliothek vor. Für andere Umgebungen und XML-Anwendungen müssen die in diesem Dokument beschriebenen Erweiterungen in die Prozesse der Signaturerzeugung und der Signaturverifikation entsprechend integriert werden. Es ist das erklärte Ziel der Projektbeteiligten, fortan auf Basis der XSpRES-Projektergebnisse weiter an XSW zu forschen, um durch einen kontinuierlichen Prozess die XSpRES-Entwicklungen am aktuellen Stand der Forschung und Technik zu halten bzw. diesen durch weitere Arbeiten mit den XSpRES-Komponenten weiter zu beeinflussen und zu prägen. Bundesamt für Sicherheit in der Informationstechnik 23

24 9 Referenzen 9 Referenzen Bibliography XML: T. Bray, E.Maler, J.Paoli, C. M. Sperberg-McQueen, Extensible Markup Language (XML) 1.0 (Second Edition), 2000 XML-C14N: J. Boyer, Canonical XML, 2001 XML-EXC: Boyer, D. Eastlake, J. Reagle, Exclusive XML Canonicalization, 2002 XML-DSig: D. Eastlake, J. Reagle, D. Solo, XML-Signature Syntax and Processing, 2001 XPath: J. Clark, S. DeRose, XML Path Language (XPath) Version 1.0, 1999 XPath-Filter2: J. Boyer, M. Hughes, J. Reagle, XML-Signaturem XPath Filter 2.0, 2002 XML-NS: T. Bray, D. Hollander, A. Layman, Namespaces in XML, 1999 XML-Schema: D. Beech, M. Maloney, N. Mendelsohn, H. Thompson, et al., XML Schema, 2001 BSP: K. S. Morrison, A. Barbir, M. McIntosh, M. Gudgin, Basic Security Profile Version 1.0, 2007 SOAP: L. Mitra, Y. Lafon, et al., SOAP Version 1.2, 2007 WS-Policy: S. Bajaj, et al., Web Services Policy Framework, 2006 WS-SecurityPolicy: G. Della-Libera, et al., Web Services Security Policy Language (WS- SecurityPolicy), 2005 WSDL 1.1: E. Christensen, et al., Web Services Description Language (WSDL) 1.1, 2001 DSAPI: Nadalin, Mullan, JSR 105: XML Digital Signature APIs, 2005 DSS:, Digital Signature Standard, 1994 ApacheRampart:, Apache Rampart - Axis2 Security Module,, CIXSE: Hill, Command Injection in XML Signatures and Encryption, 2007 FastXPath: Sebastian Gajek, Meiko Jensen, Lijun Liao, and Jörg Schwenk, Analysis of Signature Wrapping Attacks and Countermeasures, 2009 SWS09: M. Jensen, L. Liao, J. Schwenk, The Curse of Namespaces in the Domain of XML Signature, Bundesamt für Sicherheit in der Informationstechnik