xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

true

SOAPHeader(optional)

XML Content XMLFault

SOAPBody SOAPEnvelope SOAPPart MIME Header Content XML or non XML AttachmentPart (Optional) MIME Header Content XML or non XML AttachmentPart (Optional) SOAP Nachricht

WebService Demo



DEMO

 Wie erstelle ich ein WebService?

 Wie nütze ich ein Webservice?

Google Service in PHP

$key = ‘dein google license Schlüssel'; require_once('nusoap.php'); $parameters = array( 'key' => $key, 'q' => 'suchtext' , 'start' => 0, 'maxResults' => 10, 'filter' => false, 'restrict' => '', 'safeSearch' => false, 'lr' => ' lang_de ', 'ie' => '', 'oe' => '' ); $soapclient = new soapclient('http://api.google.com/search/beta2'); $result = $soapclient->call('doGoogleSearch', $parameters, 'urn:GoogleSearch'); print_r ($result);

Google Service in C#

using WebService.com.google.api; const string Key = " dein google license Schlüssel" ; global::WebService.com.google.api.GoogleSearchService s = new global::WebService.com.google.api.GoogleSearchService(); global::WebService.com.google.api.GoogleSearchResult r = s.doGoogleSearch(Key, "suchtext" , 0,10, false, "", false, "lang_de" , "", ""); string data = r.estimatedTotalResultsCount+"\r\n"; foreach (global::WebService.com.google.api.ResultElement var in result.resultElements) { data += var.URL+"\r\n"; }



Google WSDL

 http://api.google.com/GoogleSearch.wsdl

Google Service Demo



DEMO

 Suchen aus eigener Anwendung durch Google

Sünden der Webentwicklung



Der Benutzer

Sünden der Webentwicklung



Spot the Bug



CREATE PROCEDURE dbo.doQuery(@id nvarchar(128)) AS DECLARE @query nchar(256) SELECT @query= ‘select ccnum from cust where id=‘‘‘ + @id + ‘‘‘‘ EXEC @query RETURN

Sünden der Webentwicklung



SQLInjection

CREATE PROCEDURE dbo.doQuery(@id nvarchar(128)) AS DECLARE @query nchar(256) SELECT @query=‘select * from cust where id=‘‘‘ + @id + ‘‘‘‘ EXEC @query RETURN 

Id= “‘1 OR 1=1‘“

CREATE PROCEDURE dbo.doQuery(@id nvarchar(128)) AS DECLARE @query nchar(256) SELECT @query=‘select * from cust where id= ‘1 OR 1=1‘‘ EXEC @query RETURN 

Id= “1' DROP TABLE cust --“



Id= “1' exec xp_cmdshell('defrag.exe') --“



Abhilfe?



Arbeiten Sie mit parametrisierten SQL-Abfragen auf dem Datenbankserver



Arbeiten Sie mit Regular Expressions, um ungültige Eingabeformate auszuschliessen

Sünden der Webentwicklung



Spot the Bug

 string status = "No"; string sqlstring = ""; } try { // SQL Zugriffscode } catch (SqlException se) { Status = sqlstring + " failed\r\n"; foreach (SqlError e in se.Errors) Status += e.Message + "\r\n"; } if (Status.CompareTo("No") != 0) { Response.WriteLine(Status);

Sünden der Webentwicklung



Information Leakage

Sünden der Webentwicklung



Lösung für Information Leakage

try { // SQL Zugriffscode } catch (SqlException se) { Status = sqlstring + " failed\r\n"; foreach (SqlError e in se.Errors) Status += e.Message + "\r\n";

WindowsIdentity user = WindowsIdentity.GetCurrent(); WindowsPrincipal prin = new WindowsPrincipal(user); if (prin.IsInRole(WindowsBuiltInRole.Administrator)) Response.WriteLine(Status); else { Response.Write("An error occurred, please bug your admin"); EventLog.WriteEntry("SqlApp", Status, EventLogEntryType.Error); }

}

Sünden der Webentwicklung



TMI - Too Much Information

 Benutzername oder Paßwort falsch?

 Versionsinformationen verwendeter Software   IP-Adressen, MAC-Adressen, etc...

Pfade  Genaue Fehlermeldungen 

Abhilfe?

 Informationen zur Fehlersuche an vertrauenswürdiger Stelle ablegen  EventLog  Ggf. Geeignet abgesichertes Logfile  Informationen nur an Administratoren ausgeben

Danke



Sicherheit



Zur Person



Dipl. Inf. (FH) Guido Nippe

 Wirtschaftsinformatik FH Dortmund    aktuell Master-Studiengang Informatik Microsoft Student Partner Microsoft Certified Professional

Inhalt



Web-Service Sicherheit



SSL als erster Ansatz



Probleme bei SSL



Standards für sichere Webservices



WS-Security

Web-Service Sicherheit

 In der ersten Web-Services-Euphorie wurde Sicherheit wenig beachtet  Heute aber zentrale Fragestellungen:  Vertrauliche Nutzung von Web Services?

   Authentifizierung von Client und Server?

Integrität der ausgetauschten Dokumente?

Zugriffssteuerung, Verfügbarkeit?

 Wichtiges Problem:  Sicherheit traditionell als zusätzlicher (add-on) Dienst, z.B. auf der Basis von Firewalls  Web Services sind aber so entworfen, dass sie Firewalls leicht überwinden  Integrierte Lösung notwendig

SSL als erster Ansatz

SSL Security    Verschlüsselte Übertragung Authentifizierung des Servers Authentifizierung des Client (selten)

Probleme bei SSL

SSL Security  Nur bei SOAP über HTTP  Gesicherte Verbindung auf Transportebene, nicht des XML-Dokuments selbst  Sicherung von Punkt zu Punkt nicht Ende zu Ende  Problematisch besonders bei mehrstufigem Workflow Beispiel: Kreditkartendaten zum Webshop – Weiterleitung an Abrechnungsstelle

Standards für sichere Webservices

 Security Assertion Markup Language (SAML)  Trust context service  XML Digital Signatures (XML-DigSig)  Integrität für XML-Dokumnente und Attribute  XML Encryption (XML-Enc)  Vertraulichkeit für XML-Dokumente und Attribute  eXtensible Access Control Markup Language (XACML)  XML Schema, das die Darstellung und Verarbeitung von Autorisierungs Policies standardisiert  XML Key Management Specification (XKMS)  Auf XML basierender Schlüssel-Verwaltungs-Dienst  Extensible Rights Markup Language (XrML).  Universelle Sprache zur sicheren Beschreibung von digitalen Nutzungsrechten für vertrauliche Inhalte und Dienste  WS-Security  Sicherheitsstandards für Web-Services und SOAP

WS-Security

 Ursprüngliche Spezifikation wurde Oktober 2001 von Microsoft, IBM und VeriSign freigegeben  Definiert einen Standardsatz an SOAP-Erweiterungen, die es Anwendungen erlauben, sichere SOAP-Nachrichten auszutauschen  Ermöglicht die Implementierung von Mechanismen zum Austausch von Authentifizierungsmerkmalen, zur Nachrichtenintegrität und zur Vertraulichkeit  Setzt bestehende Standards und Spezifikationen wie     X.509, Kerberos (Authentifizierung) XML Encryption (Vertraulichkeit) XML Signature (Integrität) XML Canonicalization (Vorbereitung des XML-Dokumentes) wirksam ein

Implementierung WS-Security mit WSE 3.0

 Microsoft patterns & practices Group  Web-Service-Enhancements 3.0

1) 2) 3) Client Sendet in der Anfrage Benutzername/Passwort und einen generierten Sitzungsschlüssel, verschlüsselt mit dem öffentlichen Schlüssel des Servers, an den Server Server überprüft Benutzername/Passwort gegen das Active Directory Server antwortet auf die Anfrage des Clients

Asymmetrische Verschlüsselung

Zur Person



Dipl. Inf. (FH) Matthias Besenfelder

 Wirtschaftsinformatik FH Dortmund   aktuell Master-Studiengang Informatik Microsoft Certified Professional

Verwundbarkeit von Web-Services



Die bisher besprochenen Sicherheitsstandards sind eine gute Grundlage zur

   Authentifizierung, Signierung (Integrität) und Verschlüsselung.



Aber: Es gibt Verwundbarkeiten in der Anwendung selbst!



Kurz gesagt: SSL schützt nicht gegen SQL Injections

Verwundbarkeit von Web-Services

Verwundbarkeit von Web-Services

Dieser Teil des Vortrags behandelt Angriffe auf den Schichten



XML

 XML ist mittlerweile von einer großen Familie an Standards umgeben:    XSLT XSD XPath   XQuery DTD…   Wenige Menschen verstehen die wichtigsten Aspekte der Technologien Keiner versteht alle Aspekte 

SOAP

 Aktuelle Entwicklungsumgebungen verwandeln zwei Zeilen Code in vollständige Web-Services.

 Die einfache Entwicklung lenkt oft von sicherheitskritischen Aspekten ab, wie etwa der Serialisierung.

Verwundbarkeit von Web-Services XML



XML ist auf einigen wenigen Regeln aufgebaut, etwa

 Nur ein Root-Node,  Tags müssen geöffnet und geschlossen werden, … 

Ein Angriff auf einen Web Service setzt gültiges XML voraus, da ansonsten der Parser den Angriff frühzeitig verwirft.



XML Schemas können viele Angriffe verhindern, sofern sie sinnvoll eingesetzt werden.

 Injections können z.B. durch Eingaberestriktionen verhindert werden.

Verwundbarkeit von Web-Services XML - DoS



Es gibt zwei Typen von XML-Parsern



SAX (Schritt für Schritt)

 Generell nicht anfällig für DoS-Attacken 

DOM

 Angriff: DoS Extrem komplizierte, aber valides XML wird gesendet. Der Speicherbedarf ist enorm. Dieser Angriff multipliziert extrem gut (XML parsen), andere DoS-Typen sind wesentlich aufwendiger.



Custom-Parsers

 sehr anfällig für Angriffe (z.B. parsen über RegEx)

Verwundbarkeit von Web-Services XML - CDATA

CDATA-Felder



XML erlaubt über CDATA-Felder, nicht-erlaubte Zeichen zu übertragen.

 Entwickler unterliegen oft der Annahme, dass bestimmte Datentypen nicht in XML eingebettet werden können. Das führt zur Verwendung von CDATA-Feldern.

 Beim Parsen werden CDATA-Komponenten getrennt. Es gibt keine weitere Filterung!



Wo entstehen Angriffsmöglichkeiten?

 SQL-Injection  XML-Injection  XPath-Injection  XSS (Cross-Site-Scripting)

Verwundbarkeit von Web-Services XML - CDATA

Beispiel Cross-Site Scripting über CDATA-Feld

SCRIPT ]]> alert(‘XSS’); /SCRIPT ]]>

Beispiel SQL Injection über CDATA-Feld

Verwundbarkeit von Web-Services XML - XPath



XPath erlaubt das einfache Auffinden von Informationen in einem XML-Dokument



XPath kann dazu benutzt werden, auf XML fähige Datenbanken zuzugreifen.

  SQL Server 2000 und 2005, Oracle 8i+, … 

Warum ist das gefährlich?

 XPath verwendet Trennzeichen zwischen Code und Daten  Hochkomma ´  Im Gegensatz zu SQL gibt es keine Zugriffskontrolle in XML oder XPath 

Gelingt es einem Angreifer, Daten in einer XPath-Abfrage zu kontrollieren, kann er auf beliebige Teile der XML-Datei zugreifen oder beliebige Daten zurückgeben

Verwundbarkeit von Web-Services XML - XPath



XPath-Beispiel BMW M3 CSL



XPath-Queries //auto Gibt alle auto Elemente im Dokument zurück //auto/[name=`M3 CSL`] Gibt alle autos zurück, die eine Child-Node name mit dem Wert M3 CSL haben

Verwundbarkeit von Web-Services XML - XPath



Beispiel – XPath Abfrage von Username und Passwort in XML //user[name=` Matthias ` and pass=` willrein `]



Gibt den Benutzer mit Name und Passwort zurück.

//user[name=` Matthias` or 1=1 or ``=` ` and pass=` willrein `]



Gibt alle Benutzer zurück.

//user[name=` Matthias` or userid=1 or ``=` ` and pass=` willrein `]/userid



Gibt alle Benutzer mit userid=1 zurück.

Verwundbarkeit von Web-Services SOAP - WSDL



SOAP-Schnittstellen werden durch WSDL beschrieben (Web Services Description Language)

 WSDLs sind oft sehr komplex  WSDLs werden weder manuell erstellt noch gelesen  WSDLs sind einfach zu bekommen ( http://api.google.com/GoogleSearch.wsdl

) 

WSDLs verraten einem Angreifer alles, was er zum Zugriff auf die Schnittstelle des Web-Services braucht.

  Typen Nachrichten, …  Das Freigeben all dieser Informationen ist nicht erforderlich, wenn nicht beliebige Clients auf den Service zugreifen sollen!

Verwundbarkeit von Web-Services SOAP - WSDL



Angriff: Vermeintlich „versteckte“ Debug-Methoden werden versehentlich über WSDL offengelegt.

 Besondere Gefahr bei klassischen Anwendungen, die zum Web-Service portiert wurden!



Vorgänge, die nur durch Geheimhaltung oder Verworrenheit sicher sind, werden eventuell durch WSDL bekannt.

 Beispiel unverschlüsselte Übertragungen.



Manuelles Entfernen von kritischen Teilen aus WSDLs hilft nicht immer, da oft Methoden zum automatischen Generieren der WSDL existieren.

Verwundbarkeit von Web-Services SOAP



SOAP Header bieten Informationen, wie eine Nachricht behandelt werden soll.

 Oft überflüssig, aber von Web-Service-Frameworks generiert und beachtet.

 Angriff: XML DoS im SOAP-Header 

Session Management

 SOAP ist statuslos, daher muss der Entwickler den Status verwalten.

 Angriff: Replay-Attacks

Verwundbarkeit von Web-Services DoS



Alle DoS-Angriffe versuchen, Multiplikatoren zu finden

 CPU-Zeit    Tiefe Strukturen Referenzen auf externe Dokumente (Timeouts etc.) DOM für komplexe XML-Dokumente  Speicherverbrauch   Tiefe und breite Strukturen Große Datenmengen in häufig verwendeten Feldern.

 Datenbankverbindungen  Oft ein einfacher Angriffspunkt, da wenige Datenbanken einen Flaschenhals bilden.

Verwundbarkeit von Web-Services DoS



Was einen schlagkräftigen Angriff ausmacht

 Gültiger SOAP-Request    Korrekte DTD-/XSD-Syntax Entspricht einer tatsächlichen SOAP-Methode Eventuell ist eine gültige Session-ID erforderlich  Geschwindigkeit   Mehrere Prozesse Für manche Angriffe muss auf eine Antwort reagiert werden 

Wie verteidigt man sich?

 DoS-Angriffe auf Web Services müssen getestet werden!

 Die Komplexität einer Anfrage sollte vor dem Parsen geprüft werden  XML-Firewalls  Strict XML-Schema verification

Verwundbarkeit von Web-Services Fazit



Web Services sind mächtig, einfach zu bedienen und ein offener Standard

 D.h. sie sind außergewöhnlich gefährlich.



Viele Sicherheitsfragen sind nicht geklärt

 Die sich schnell entwickelnden Standards müssen analysiert werden  WS-Security    WS-Routing WS-Inspection WS …..

Links



Web Services Enhancements (WSE)

 http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx



Microsoft patterns & practices Home

 http://msdn.microsoft.com/practices/ 

Security DevDays 2006 Dank an Dirk Primbs

 https://www.microsoft.com/germany/msdn/experts/DirkPrimbs/default.mspx



Wikipedia

 http://www.wikipedia.de  _