Dipl. Inf. (FH) Paul Mizel

IT-Sicherheit
Web Service Security
Dipl. Inf. (FH) Paul Mizel
Email: [email protected]
Dipl. Inf. (FH) Matthias Besenfelder
Dipl. Inf. (FH) Guido Nippe
Dipl. Inf. (FH) Paul Mizel
[email protected]
Zur Person
 Dipl. Inf. (FH) Paul Mizel




Allgemeine Informatik FH Dortmund
aktuell Master-Studiengang Informatik
Microsoft Student Partner
Microsoft Certified Professional
Inhalt
 Was ist ein WebService?
 Begriffe
 Google Service Demo
 Sünden der Web-Entwicklung
Was ist ein WebService?
WebService
Firewall
Benutzer
WebServer
DatenbankServer
Begriffe
 UDDI Universal Description, Discovery and Integration 3.0.2
 http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.220041019.htm
 WSDL Web Services Description Language (WSDL) 1.1
 http://www.w3.org/TR/wsdl
 SOAP Simple Object Access Protocol 1.2
 http://www.w3.org/TR/soap12
 RPC Remote Procedure Call
 CORBA, DCOM, RMI
 XML Extensible Markup Language
 http://www.w3.org/XML/
SOAP
 Request
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:validate
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:CardValidator">
<number xsi:type="xsd:string">1234 5678 9876 5432</number>
<valid xsi:type="xsd:string">12/08</valid>
</ns1:validate>
</soapenv:Body>
</soapenv:Envelope>
 Response
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:validateResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:CardValidator">
<addReturn xsi:type="xsd:boolean">true</addReturn>
</ns1:validateResponse>
</soapenv:Body>
</soapenv:Envelope>
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 AutorisierungsPolicies 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)
Client Sendet in der Anfrage Benutzername/Passwort und einen generierten Sitzungsschlüssel,
verschlüsselt mit dem öffentlichen Schlüssel des Servers, an den Server
2)
Server überprüft Benutzername/Passwort gegen das Active Directory
3)
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 SQLInjections
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
<TAG1>
<![CDATA[<]]>SCRIPT<![CDATA[>]]>
alert(‘XSS’);
<![CDATA[<]]>/SCRIPT<![CDATA[>]]>
</TAG1>
Beispiel SQL-Injection über CDATA-Feld
<TAG2>
<![CDATA[‘or 1=1 or ‘’=‘]]>
</TAG2>
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
<auto>
<hersteller>BMW</hersteller>
<name>M3 CSL</name>
</auto>
 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
 _