Freigeben über

Erstellen sicherer Webdienste

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Überblick Überblick
Risiken und Gegenmaßnahmen Risiken und Gegenmaßnahmen
Entwurfsüberlegungen Entwurfsüberlegungen
Eingabeüberprüfung Eingabeüberprüfung
Authentifizierung Authentifizierung
Autorisierung Autorisierung
Vertrauliche Daten Vertrauliche Daten
Parametermanipulation Parametermanipulation
Ausnahmeverwaltung Ausnahmeverwaltung
Überwachen und Protokollieren Überwachen und Protokollieren
Überlegungen zu Proxy-Einstellungen Überlegungen zu Proxy-Einstellungen
Überlegungen zur Codezugriffssicherheit Überlegungen zur Codezugriffssicherheit
Überlegungen zur Bereitstellung Überlegungen zur Bereitstellung
Zusammenfassung Zusammenfassung
Weitere Quellen Weitere Quellen

Modulübersicht

Webdienste werden von immer mehr Unternehmen und Organisationen bereitgestellt. Dies geschieht jedoch meist ohne ein umfassendes Verständnis der Sicherheitsaspekte. In diesem Modul wird das sichere Entwerfen, Konfigurieren und Bereitstellen von Webdiensten erläutert. Wie bei allen Anwendungen, die externe Anforderungen zulassen, ist eine Eingabeüberprüfung äußerst wichtig. Es werden im Folgenden verschiedene Techniken aufgezeigt, anhand derer nur wohlgeformte Anforderungen akzeptiert werden. Außerdem werden die verschiedenen Authentifizierungsmethoden ausführlich erläutert, mithilfe derer der Zugriff auf Webdienste auf autorisierte Benutzer beschränkt und sichergestellt werden kann, dass deren Aktionen protokolliert und überwacht werden.

Außerdem werden Microsoft Web Services Enhancements 1.0 für Microsoft® .NET (WSE) behandelt, die die Webdienstsicherheit (Web Services Security) und verwandte verfügbare Standards unterstützen.

 

Zielsetzung

Themenbereiche:

  • Entwerfen und Bereitstellen sicherer Webdienste.

  • Überprüfen von Webdiensteingaben mithilfe sicherer eingegebener Parameter und XSD-Schemata.

  • Authentifizieren von Webdienstclients.

  • Autorisieren des Zugriffs auf Ihre Webdienste.

  • Schützen der Vertraulichkeit und Integrität von Webdienstmeldungen.

  • Auswahl der Sicherheitsoptionen für eine Implementierung entsprechend Ihres Bereitstellungsszenarios (Intranet, Extranet und Internet).

  • Information über Web Services Enhancements 1.0 für Microsoft .NET (WSE).

  • Erkennen, wie Codezugriffssicherheit für die Sicherung von .NET Framework-Consumercode verwendet werden kann.

  • Information über Gegenmaßnahmen, um mit allgemeinen Bedrohungen der Webdienste umzugehen. Zu diesen gehören das Abhören des Netzwerks, nicht autorisierter Zugriff, Änderungen an den Parametern, Offenlegung von Konfigurationsdaten und Nachrichtenwiedergabe.

 

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

  • Microsoft® Windows®2000 Server und Microsoft Windows Server™2003

  • Microsoft .NET Framework 1.1 und ASP.NET 1.1

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Lesen Sie Modul 19, " Schützen der ASP.NET-Anwendung und -Webdienste ". Dieses Modul wendet sich an Administratoren, damit diese mithilfe einer sinnvollen Konfiguration teilweise sichere ASP.NET-Anwendungen oder -Webdienste in einen sicheren Status setzen können.

  • Lesen Sie Modul 17, " Schützen des Anwendungsservers ". Lesen Sie Modul 17, um sich mit Maßnahmen im Bezug auf Remoteanwendungsserver vertraut zu machen.

  • Verwenden Sie die Prüfliste " Schützen von Webdiensten " im entsprechenden Abschnitt in diesem Handbuch. Die Prüfliste ist eine Zusammenfassung der erforderlichen Sicherheitsmaßnahmen für das Erstellen und Konfigurieren eines sicheren Webdienstes.

  • Verwenden Sie dieses Modul, um Risiken auf Meldungsebene zu verstehen und diesen entsprechend zu begegnen.

  • Verwenden Sie die Anwendungskategorien als ein Mittel gegen verbreitete Probleme. In den jeweiligen Abschnitten finden Sie wichtige Informationen zur Verwendung der einzelnen Kategorien.

 

Überblick

Webdienste werden von immer mehr Firmen verwendet, um Produkte und Dienste Geschäftspartnern und Kunden vorzustellen, sei es im Internet oder in Unternehmensextranets. Die Sicherheitsanforderungen dieser Dienstanbieter sind von größter Wichtigkeit. In manchen Fällen, insbesondere bei Intranet- oder Extranetszenarien, bei denen eine gewisse Kontrolle über beide Endpunkte besteht, können die vom Betriebssystem oder von Internetinformationsdiensten (IIS) bereitgestellten plattformbasierten Sicherheitsdienste für Point-to-Point-Sicherheitslösungen verwendet werden. Dennoch erfordern die meldungsbasierte Architektur von Webdiensten und die heterogenen Umgebungen, die immer mehr über Vertrauensgrenzen hinweg verwendet werden, neue Maßnahmen. Diese Szenarien erfordern eine Sicherheit auf Meldungsebene, um plattformübergreifende Interoperabilität und Routing über mehrere intermediäre Knoten zu unterstützen.

Die Webdienstsicherheit (Web Services Security) wird als Sicherheitsstandard entworfen, um diese Probleme zu beheben. Microsoft hat Web Services Enhancements 1.0 für Microsoft .NET (WSE) veröffentlicht, die Webdienstsicherheit und weitere in der Entstehung befindliche Standards unterstützen. WSE ermöglicht das Implementieren von Sicherheitslösungen auf Meldungsebene einschließlich Authentifizierung, Verschlüsselung und digitaler Signaturen.

Hinweis: Die von WSE unterstützten Spezifikationen und Standards befinden sich teilweise noch in der Entwicklung. Daher kann die Kompatibilität mit zukünftigen Produktversionen derzeit nicht garantiert werden. Derzeit werden noch Interoperabilitätstests mit Toolkits von Drittanbietern wie IBM und VeriSign durchgeführt.

 

Risiken und Gegenmaßnahmen

Um sichere Webdienste erstellen zu können, müssen Sie die entsprechenden Risiken kennen. Die Hauptgefahren für Webdienste sind:

  • Nicht autorisierter Zugriff

  • Parametermanipulation

  • Abhören des Netzwerks

  • Offenlegung von Konfigurationsdaten

  • Nachrichtenwiedergabe

In Abbildung 12.1 finden Sie die Hauptrisiken und -angriffe auf Webdienste.

Hauptrisiken für Webdienste

Abbildung 12.1
Hauptrisiken für Webdienste

Nicht autorisierter Zugriff

Webdienste, die wichtige oder geheime Informationen bereitstellen, sollten Benutzer authentifizieren und autorisieren. Unsichere Authentifizierung und Autorisierung kann ausgenutzt werden, um nicht autorisierten Zugriff auf wichtige Informationen und Verfahren zu erhalten.

Sicherheitslücken

Sicherheitslücken, die zu nicht autorisiertem Zugriff über Webdienste führen können, umfassen:

  • Fehlende Authentifizierung

  • Kennwörter in Klartext in SOAP-Headern

  • Standardauthentifizierung über einen unverschlüsselten Kommunikationskanal

Gegenmaßnahmen

Folgende Gegenmaßnahmen verhindern nicht autorisierten Zugriff:

  • Verwenden von Kennwort-Digests in SOAP-Headern für die Authentifizierung.

  • Verwenden von Kerberos-Tickets in SOAP-Headern für die Authentifizierung.

  • Verwenden von X.509-Zertifikaten in SOAP-Headern für die Authentifizierung.

  • Verwenden der Windows-Authentifizierung.

  • Verwenden von rollenbasierter Autorisierung, um den Zugriff auf Webdienste einzuschränken. Dies erfolgt entweder über eine URL-Autorisierung für die Steuerung des Zugriffs auf die Webdienstdatei (.asmx) oder auf der Webebene mithilfe von Anforderungen für Berechtigungsprinzipale.

Parametermanipulation

Die Parametermanipulation bezieht sich auf die nicht autorisierte Änderung von Daten, die zwischen dem Webdienstbenutzer und dem Webdienst gesendet werden. So kann ein Angreifer beispielsweise eine Webdienstmeldung beim Passieren eines Zwischenknotens auf dem Weg zur Zieladresse abfangen und diese ändern, bevor sie an den eigentlichen Endpunkt gesendet wird.

Sicherheitslücken

Folgende Sicherheitslücken können Parametermanipulationen ermöglichen:

  • Nicht digital signierte und somit fälschungssichere Meldungen

  • Nicht verschlüsselte und somit weder private noch fälschungssichere Meldungen

Gegenmaßnahmen

Folgende Gegenmaßnahmen verhindern Parametermanipulationen:

  • Digitales Signieren von Meldungen. Die digitale Signatur wird vom Empfänger verwendet, um sicherzustellen, dass an der Meldung keine unerlaubten Änderungen vorgenommen wurden.

  • Verschlüsseln des Meldungsinhalts, um Datenschutz und Fälschungssicherheit sicherzustellen.

Abhören des Netzwerks

Durch das Abhören eines Netzwerks ist ein Angreifer in der Lage, Webdienstmeldungen während der Übertragung anzuzeigen. So kann ein Angreifer beispielsweise mithilfe von Netzwerküberwachungssoftware die in einer SOAP-Meldung enthaltenen Informationen erhalten. Dabei kann es sich um wichtige Informationen der Anwendungsebene oder um Anmeldeinformationen handeln.

Sicherheitslücken

Sicherheitslücken, die ein erfolgreiches Abhören des Netzwerks ermöglichen, umfassen:

  • Anmeldeinformationen in Klartext in SOAP-Headern

  • Fehlende Verschlüsselung auf Meldungsebene

  • Fehlende Verschlüsselung auf Übertragungsebene

Gegenmaßnahmen

Mithilfe folgender Gegenmaßnahmen können wichtige SOAP-Meldungen bei der Übertragung über das Netzwerk geschützt werden:

  • Verwenden einer Verschlüsselung auf Übertragungsebene (beispielsweise SSL oder IPSec). Dies ist nur möglich, wenn Sie beide Endpunkte steuern.

  • Verschlüsseln des Meldungsinhalts, um den Datenschutz sicherzustellen. Dies gilt für Szenarien, in denen Meldungen über Zwischenknoten zur endgültigen Zieladresse gesendet werden.

Offenlegung von Konfigurationsdaten

Es gibt zwei Möglichkeiten, Konfigurationsdaten von Webdiensten offen zu legen. Zum einen unterstützt der Webdienst möglicherweise eine dynamische Erzeugung von WDSL (Web Service Description Language) oder er stellt WSDL-Informationen in herunterladbaren Dateien bereit, die auf dem Webserver verfügbar sind. Dies ist allerdings nicht immer wünschenswert.

Hinweis: WSDL beschreibt die Merkmale eines Webdienstes, beispielsweise die Verfahrenssignaturen und unterstützte Protokolle.

Zweitens kann der Webdienst durch eine inadäquate Ausnahmeverwaltung wichtige interne Implementierungsinformationen offen legen, die von Angreifern genutzt werden.

Sicherheitslücken

Folgende Sicherheitslücken können zu einer Offenlegung von Konfigurationsdaten führen:

  • Nicht eingeschränkte WSDL-Dateien, die für einen Download vom Webserver verfügbar sind

  • Ein eingeschränkter Webdienst, der die dynamische Erzeugung von WSDL unterstützt und nicht autorisierten Kunden den Zugang auf Webdienstmerkmale ermöglicht

  • Unsichere Ausnahmeverwaltung

Gegenmaßnahmen

Mithilfe folgender Gegenmaßnahmen kann die ungewollte Offenlegung von Konfigurationsdaten verhindert werden:

  • Autorisieren des Zugriffs auf WSDL-Dateien mithilfe von NTFS-Berechtigungen.

  • Entfernen von WSDL-Dateien vom Webserver.

  • Deaktivieren der Dokumentationsprotokolle zur Verhinderung der automatischen Erzeugung von WSDL.

  • Auffangen von Ausnahmen und Erzeugen einer SoapException oder SoapHeaderException, die lediglich minimale und harmlose Informationen zum Client zurückgeben.

Meldungswiedergabe

Webdienstmeldungen werden möglicherweise an mehrere Zwischenserver übertragen. Bei einem Meldungswiedergabeangriff fängt ein Angreifer eine Meldung ab, kopiert sie und gibt sie an den Webdienst zurück, indem er die Identität des Clients annimmt. Dabei kann die Meldung möglicherweise geändert werden.

Sicherheitslücken

Folgende Sicherheitslücken können zu einer Meldungswiedergabe führen:

  • Nicht verschlüsselte Meldungen

  • Nicht digital signierte und somit nicht fälschungssichere Meldungen

  • Doppelte Meldungen, die nicht erkannt werden, da keine eindeutige Meldungskennung verwendet wird

Angriffe

Zu den häufigsten Arten von Meldungswiedergabeangriffen gehören:

  • Standardwiedergabeangriff. Der Angreifer fängt eine Meldung ab, kopiert sie, gibt die gleiche Meldung wieder und gibt sich als Client aus. Bei dieser Angriffsart muss der bösartige Benutzer den Inhalt der Meldung nicht kennen.

  • Man-in-the-Middle-Angriff. Der Angreifer fängt die Meldung ab, ändert Teile des Inhalts (beispielsweise eine Lieferadresse) und gibt Sie anschließend auf dem Webdienst wieder.

Gegenmaßnahmen

Folgende Gegenmaßnahmen können Wiedergabeangriffe verhindern:

  • Verwenden eines verschlüsselten Kommunikationskanals, beispielsweise SSL.

  • Verschlüsseln des Meldungsinhalts, um Datenschutz und Fälschungssicherheit sicherzustellen. Dies verhindert zwar keine Standardwiedergabeangriffe, sehr wohl jedoch Man-in-the-Middle-Angriffe, bei denen der Meldungsinhalt geändert wird.

  • Verwenden einer eindeutigen Meldungskennung oder Nonce für jede Anforderung, um doppelte Meldungen zu erkennen und digitale Signaturen als Schutz vor Fälschungen.

    Hinweis: Eine Nonce ist ein kryptografisch eindeutiger Wert für die Anforderung.

    Bei der Antwort des Servers an den Client wird eine eindeutige Kennung gesendet und die Meldung wird mit einer Signatur versehen, die die Kennung enthält. Bei einer weiteren Anforderung des Client wird die Kennung der Meldung hinzugefügt. Der Server überprüft, ob die mit der vorigen Meldung an den Client gesendete Kennung in der neuen Anforderung des Client enthalten ist. Handelt es sich um eine andere Kennung, wird die Anforderung vom Server abgelehnt, da es sich um einen Wiedergabeangriff handeln könnte.

    Angreifer können die Meldungskennung nicht manipulieren, da die Meldung signiert ist. Beachten Sie, dass dies lediglich vor von Clients ausgelösten Wiedergabeangriffen unter Verwendung der Meldungsanforderung schützt, nicht jedoch den Client vor wiedergegebenen Antworten.

 

Entwurfsüberlegungen

Vor dem Entwickeln von Webdiensten sind beim Entwurf einige wichtige Aspekte zu beachten. Folgendes sind die wichtigsten Sicherheitserwägungen:

  • Authentifizierungsanforderungen

  • Datenschutz- und Integritätsanforderungen

  • Identitäten für den Ressourcenzugriff

  • Codezugriffssicherheit

Authentifizierungsanforderungen

Wenn Ihr Webdienst wichtige oder geheime Informationen bereitstellt, ist eine Authentifizierung von Benutzern unerlässlich. In Windows-Umgebungen kann die Windows-Authentifizierung verwendet werden. Wenn Sie jedoch nicht beide Endpunkte steuern können, bietet WSE Authentifizierungslösungen, die den Webdienstsicherheitsstandards entsprechen. WSE bietet ein Standardframework für die Verwendung von SOAP-Headern, um die Authentifizierungsinformationen als Benutzernamen und Kennwort, Kerberos-Tickets, X.509-Zertifikate oder benutzerdefinierte Tokens zu übertragen. Weitere Informationen finden Sie weiter unten in diesem Modul im Abschnitt "Authentifizierung".

Datenschutz- und Integritätsanforderungen

Wenn wichtige Anwendungsdaten in Webdienstanfragen oder Antwortmeldungen übertragen werden, müssen diese während der Übertragung vertraulich und unverändert bleiben. WSE bietet eine Integritätsprüfung mithilfe digitaler Signaturen sowie XML-Verschlüsselung wichtiger Elemente des vollständigen Meldungsinhalts. Von Vorteil ist hierbei, dass diese Maßnahmen auf dem Webdienstsicherheitsstandard beruhen. Außerdem wird eine Lösung für Meldungen geboten, die mehrere Zwischenknoten passieren.

Wahlweise kann eine Verschlüsselung auf Übertragungsebene über SSL oder IPSec-Kanäle verwendet werden. Diese Lösungen sind jedoch nur möglich, wenn Sie beide Endpunkte steuern.

Identitäten für den Ressourcenzugriff

In der Standardeinstellungen wechseln ASP.NET-Webdienste nicht die Identität und verwenden für lokalen und Remoteressourcenzugriff das ASPNET-Prozesskonto mit den geringsten Berechtigungen. Dieses ASPNET-Prozesskonto kann verwendet werden, um auf Remotenetzwerkressourcen wie SQL Server zuzugreifen, die Windows-Authentifizierung erfordern, indem Sie auf dem Datenbankserver ein gespiegeltes lokales Konto erstellen.

Hinweis: In Windows Server 2003 wird das Netzwerkdienstkonto in der Standardeinstellung für das Ausführen von Webdiensten verwendet.

Weitere Informationen zur Verwendung des ASP.NET-Prozesskontos für Remotedatenbankzugriff finden Sie im Abschnitt "Datenzugriff" in Modul 19, "Schützen der ASP.NET-Anwendung und der -Webdienste".

Wenn Sie Identitätswechsel verwenden, gelten die Probleme und Erwägungen für Webanwendungen ebenfalls für Webdienste. Weitere Informationen finden Sie in den Abschnitten "Identitätswechsel" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente", und in Modul 19, "Schützen der ASP.NET-Anwendung und -Webdienste".

Codezugriffssicherheit

Überprüfen Sie die in der Sicherheitsrichtlinie Ihrer Zielbereitstellungsumgebung festgelegte Vertrauensstufe. Die durch die Konfiguration des Elements <trust> für Ihren Webdienst festgelegte Vertrauensstufe bestimmt, auf welche Arten von Ressourcen der Webdienst zugreifen und welche privilegierten Vorgänge er ausführen darf.

Außerdem legt die Vertrauensstufe der Webanwendung beim Aufrufen eines Webdienstes von einer ASP.NET-Webanwendung den Bereich von aufrufbaren Webdiensten fest. So kann eine für die Vertrauensstufe Mittel konfigurierte Webanwendung in der Standardeinstellung lediglich Webdienste vom lokalen Computer aufrufen.

Weitere Informationen zum Aufrufen von Webdiensten von mittleren und anderen nur teilweise vertrauenswürdigen Webanwendungen finden Sie in Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET".

 

Eingabeüberprüfung

Wie bei anderen Anwendungen, die Eingabedaten akzeptieren, müssen auch bei Webdiensten die eingehenden Daten überprüft werden, um Geschäftsrichtlinien zu erzwingen und mögliche Sicherheitsprobleme zu vermeiden. Mit dem Attribut WebMethod markierte Webmethoden sind die Einstiegspunkte der Webdienste. Webmethoden können Eingabeparameter mit strikter Typbindung oder Parameter mit flexibler Typbindung akzeptieren, die häufig als Zeichenfolgendaten übertragen werden. Dies entscheidet sich meist an der Bandbreite und Art von Kunden, für die der Webdienst entwickelt wurde.

Parameter mit strikter Typbindung

Wenn Sie Parameter mit strikter Typbindung verwenden, die vom .NET Framework-Typsystem beschrieben werden (etwa ganze Zahlen, Duplikate, Daten oder andere benutzerdefinierte Objekttypen wie Adresse oder Mitarbeiter), enthält das automatisch erzeugte XSD-Schema (XML Schema Definition) eine typisierte Beschreibung der Daten. Mithilfe dieser Beschreibung können Benutzer entsprechend formatierte XML innerhalb der SOAP-Anforderungen entwerfen, die an die Webmethoden gesendet werden. ASP.NET verwendet die Klasse System.Xml.Serialization.XmlSerializer, um die eingehende SOAP-Meldung in CLR (Common Language Runtime)-Objekte zu deserialisieren. Im folgenden Beispiel finden Sie eine Webmethode, die Eingaben mit strikter Typbindung akzeptiert, die aus vordefinierten Datentypen besteht.

[WebMethod]
public void CreateEmployee(string name, int age, decimal salary) {...}

In diesem Beispiel führt das .NET Framework-Typsystem Typüberprüfungen automatisch durch. Zur Überprüfung des im Feld Name bereitgestellten Zeichenbereichs können reguläre Ausdrücke verwendet werden. Im folgenden Codebeispiel wird die Verwendung der Klasse System.Text.RegularExpressions.Regex für eine Beschränkung des möglichen Eingabezeichenbereichs und die Überprüfung der Parameterlänge gezeigt.

if (!Regex.IsMatch(name, @"^[a-zA-Z'.`-´\s]{1,40}$"))
{
  // ungültiger Name
}

Weitere Informationen zu regulären Ausdrücken finden Sie im Abschnitt "Eingabeüberprüfung" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente". Im folgenden Beispiel finden Sie eine Webmethode, die einen benutzerdefinierten Mitarbeiter-Datentyp akzeptiert.

using Employees;  // Benutzerdefinierter Namespace
[WebMethod]
	
public void CreateEmployee(Employee emp) { ... }

Der Kunde muss Ihr XSD-Schema kennen, um Ihren Webdienst aufrufen zu können. Wenn es sich um eine .NET Framework-Clientanwendung handelt, wird diese wie folgt ein Mitarbeiterobjekt übertragen:

using Employees;
Employee emp = new Employee();
// Mitarbeiterfelder füllen
// Mitarbeiterobjekt an Webdienst senden
wsProxy.CreateEmployee(emp);

Kundenanwendungen, die nicht auf dem .NET-Framework beruhen, müssen die XML-Eingabe manuell erstellen. Diese muss auf der Schemadefinition des für den Webdienst verantwortlichen Unternehmens beruhen.

Der Vorteil der strikten Typbindung ist die Verarbeitung und Überprüfung der Eingabedaten anhand der Typdefinition durch das .NET Framework. Innerhalb der Webmethode müssen die Eingabedaten möglicherweise dennoch beschränkt werden. Wenn beispielsweise das Typsystem ein gültiges Mitarbeiterobjekt bestätigt, müssen Sie die Mitarbeiterfelder dennoch weiter überprüfen. So ist zu prüfen, ob das Geburtsdatum eines Mitarbeiters länger als 18 Jahre zurückliegt. Möglicherweise müssen reguläre Ausdrücke verwendet werden, um den Zeichenbereich für Namensfelder einzuschränken, usw.

Weitere Informationen zum Beschränken der Eingabe finden Sie im Abschnitt "Eingabeüberprüfung" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente".

Parameter mit flexibler Typbindung

Wenn Sie für die willkürliche Übertragung von Daten Zeichenfolgenparameter oder Bytearrays verwenden, können Sie einige Vorteile des .NET Framework-Typsystems nicht nutzen. Sie müssen Daten zur Überprüfung manuell verarbeiten, da die automatisch erzeugte WSDL die Parameter einfach als Zeichenfolgeneingaben des Typs xsd:string beschreibt. Sie müssen wie im folgenden Beispiel systematisch auf Typ, Länge, Format und Bereich überprüfen.

[WebMethod]
public void SomeEmployeeFunction(string dateofBirth, string SSN) 
{
    . . . 
  // BEISPIEL 1: Type check the date
  try
  {
    DateTime dt = DateTime.Parse(dateofBirth).Date;
  }
  // Wenn die Typkonvertierung fehlschlägt, wird eine FormatException ausgelöst
  catch (SomeExceptionType ex)
  {
    // ungültiger Name
  }
  
  // BEISPIEL 2: Sozialversicherungsnummer nach Länge, Format und Bereich prüfen
  if( !Regex.IsMatch(empSSN,@"^\d{3}-\d{2}-\d{4}$",RegexOptions.None)) 
  {
      // ungültige Sozialversicherungsnummer
  }
}

XML-Daten

In einem klassischen Business-to-Business-Szenario ist es üblich, dass Kunden XML-Daten übertragen, die geschäftlichen Dokumenten wie etwa Aufträgen oder Rechnungen entsprechen. Die Gültigkeit der Daten muss mithilfe der Webmethode systematisch überprüft werden, bevor diese verarbeitet oder an untergeordnete Komponenten weitergeleitet werden.

Client und Server müssen ein die XML beschreibendes Schema einrichten und sich auf dieses einigen. Im folgenden Codebeispiel wird gezeigt, wie eine Webmethode die Klasse System.Xml.XmlValidatingReader verwendet, um die Eingabedaten zu überprüfen, die in diesem Beispiel eine einfache Buchbestellung beschreiben. Beachten Sie, dass die XML-Daten durch einen einfachen Zeichenfolgenparameter übertragen werden.

using System.Xml;
using System.Xml.Schema;

[WebMethod]
public void OrderBooks(string xmlBookData)
{
  try
  {
    // Erstellen und laden eines überprüfenden Reader-Objekts
    XmlValidatingReader reader = new XmlValidatingReader(xmlBookData, 
                                                         XmlNodeType.Element, 
                                                         null);
    // Anfügen des XSD-Schemas an den Leser
    reader.Schemas.Add("urn:bookstore-schema",
                       @"https://localhost/WSBooks/bookschema.xsd");
    // Festlegen des Überprüfungstyps für das XSD-Schema. 
    // XDR-Schemata und DTDs werden ebenfalls unterstützt
    reader.ValidationType = ValidationType.Schema;
    // Erstellen und Registrieren eines Ereignishandlers zur Verarbeitung von Überprüfungsfehlern
    reader.ValidationEventHandler += new ValidationEventHandler(
                                                   ValidationErrors );
    // Verarbeiten der Eingabedaten
    while (reader.Read())
    {
      . . .
    }
    // Überprüfung erfolgreich abgeschlossen
  }
  catch
  {
   . . .
  }
}

// Überprüfungsfehler-Ereignishandler
private static void ValidationErrors(object sender, ValidationEventArgs args)
{
  // Angaben zum Fehler unter args.Message verfügbar
  . . .
}

Im folgenden Codebeispiel wird gezeigt, wie der Kunde die vorige Webmethode aufruft:

string xmlBookData = "<book  xmlns='urn:bookstore-schema' 
                         xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>" +
                     "<title>Building Secure ASP.NET Applications</title>" +
                     "<isbn>0735618909</isbn>" +
                     "<orderQuantity>1</orderQuantity>" +
                     "</book>";
BookStore.BookService bookService = new BookStore.BookService();
bookService.OrderBooks(xmlBookData));

Im vorigen Beispiel wird zur Überprüfung der Eingabedaten folgendes einfaches XSD-Schema verwendet.

<?xml version="1.0" encoding="utf-8" ?> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns="urn:bookstore-schema" 
            elementFormDefault="qualified" 
            targetNamespace="urn:bookstore-schema">
  <xsd:element name="book" type="bookData"/>
  <xsd:complexType name="bookData">
    <xsd:sequence>
      <xsd:element name="title" type="xsd:string" />
      <xsd:element name="title" type="xsd:string" />
      <xsd:element name="orderQuantity" type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

In der folgenden Tabelle finden Sie zusätzliche komplexe Elementdefinitionen, die in XSD-Schemata verwendet werden können, um einzelne XML-Elemente weiter einzuschränken.

Tabelle 12.1: Beispiele für Elemente von XSD-Schemata

Beschreibung

Beispiel

Verwendung reguläre Ausdrücke zur Beschränkung von XML-Elementen

 
<xsd:element name="zip">
   <xsd:simpleType>
    <xsd:restriction base="xsd:string">
     <xsd:pattern value="\d{5}(-\d{4})?" />
    </xsd:restriction>
   </xsd:simpleType>
</xsd:element>

Beschränken eines Dezimalwertes auf zwei Ziffern nach dem Dezimaltrennzeichen

 
<xsd:element name="Salary">
  <xsd:simpleType>
   <xsd:restriction base="xsd:decimal">
    <xsd:fractionDigits value="2" />
   </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

Beschränken der Länge einer Eingabezeichenfolge

 
<xsd:element name="FirstName">
 <xsd:simpleType>
  <xsd:restriction base="xsd:string">
   <xsd:maxLength value="50" />
   <xsd:minLength value="2" />
  </xsd:restriction>
 </xsd:simpleType>
</xsd:element>

Beschränken der Eingabe auf durch einen Aufzählungstyp definierte Werte

 
<xsd:element name="Gender">
 <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:enumeration value="Male" />
     <xsd:enumeration value="Female" />
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

Weitere Informationen hierzu finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:

  • 307379: "How To: Validate an XML Document by Using DTD, XDR, or XSD in Visual C# .NET".

  • 318504: "How To: Validate XML Fragments Against an XML Schema in Visual C#.NET".

SQL-Injektion

Die SQL-Injektion ermöglicht Angreifern mithilfe der Datenbankanmeldung des Webdienstes das willkürliche Ausführen von Befehlen. Die SQL-Injektion kann für Webdienste ein Problem werden, wenn sie Eingabedaten zum Erstellen von SQL-Abfragen verwenden. Wenn Ihre Webmethoden auf die Datenbank zugreifen, sollte dies mithilfe von SQL-Parametern und (im Idealfall) über parametrisierte gespeicherte Prozeduren geschehen. SQL-Parameter überprüfen die Eingabe auf Typ und Länge. Außerdem stellen sie sicher, dass die Eingabe als Literaltext und nicht als ausführbarer Code behandelt wird. Weitere Informationen zu Maßnahmen gegen diese und andere SQL-Injektionen finden Sie im Abschnitt "Eingabeüberprüfung" in Modul 14, "Erstellen eines sicheren Datenzugriffs".

Cross-Site Scripting

Beim Cross-Site Scripting (XSS) nutzt ein Angreifer Ihre Anwendung, um beim Client bösartige Skripts auszuführen. Wenn sie einen Webdienst aufrufen und die Ausgaben vom Webdienst in einem HTML-Datenstrom zurück an den Client senden, stellt XSS ein mögliches Problem dar. In diesem Szenario sollten Sie die vom Webdienst erhaltenen Ausgaben in der Webanwendung zunächst codieren, bevor Sie diese an den Client zurückgeben. Dies ist insbesondere dann wichtig, wenn es sich nicht um Ihren Webdienst handelt und dieser sich außerhalb der Vertrauensgrenze der Webanwendung befindet. Weitere Informationen zu XSS-Gegenmaßnahmen finden Sie im Abschnitt "Eingabeüberprüfung" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente".

 

Authentifizierung

Wenn Ihr Webdienst wichtige oder geheime Daten ausgibt oder eingeschränkte Dienste ausführt, müssen Benutzer authentifiziert werden. Es sind mehrere Authentifizierungsschemata verfügbar, die grob in drei Kategorien eingeteilt werden können:

  • Authentifizierung auf Plattformebene

  • Authentifizierung auf Meldungsebene

  • Authentifizierung auf Anwendungsebene

Authentifizierung auf Plattformebene

Wenn Sie beide Endpunkte steuern und diese sich auf der gleichen oder einer vertrauenswürdigen Domäne befinden, können Sie zu Authentifizierung von Benutzern die Windows-Authentifizierung verwenden.

Standardauthentifizierung

Sie können IIS verwenden, um das virtuelle Verzeichnis von Webdiensten für eine Standardauthentifizierung zu konfigurieren. Dadurch müssen Kunden zunächst den Proxyserver konfigurieren und Anmeldeinformationen in Form von Benutzername und Kennwort bereitstellen. Der Proxyserver überträgt diese dann bei jeder Webdienstabfrage von diesem Proxyserver. Die Anmeldeinformationen werden in Klartext übertragen. Daher sollte lediglich die Standardauthentifizierung mit SSL verwendet werden.

Im folgenden Codebeispiel wird gezeigt, wie eine Webanwendung die Anmeldeinformationen einer Standardauthentifizierung eines Endbenutzers extrahiert und diese anschließend verwendet, um einen untergeordneten Webdienst aufzurufen, der für eine Standardauthentifizierung in IIS konfiguriert ist.

// Abrufen der Anmeldeinformationen des Client (verfügbar bei der Standardauthentifizierung)
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Festlegen der Anmeldeinformationen
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web service URL
          "Basic",
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;
Integrierte Windows-Authentifizierung

IIS ist für die Konfigurieration des virtuellen Verzeichnisses des Webdienstes für integrierte Windows-Authentifizierung zu verwenden, was abhängig von der Client- und Serverumgebung entweder zu einer Kerberos- oder NTLM-Authentifizierung führt. Dies bietet im Vergleich zur Standardauthentifizierung den Vorteil, dass die Anmeldeinformationen nicht über das Netzwerk gesendet werden, was die Risiken eines Abhörens des Netzwerks verringert.

Um einen Webdienst aufrufen zu können, der für integrierte Windows-Authentifizierung konfiguriert ist, muss der Kunde die Eigenschaft Anmeldeinformationen des Proxyservers entsprechend konfigurieren.

Um den Windows-Sicherheitskontext des Clients (entweder von einem Identitätswechselthread- oder einem Prozesstoken) auf einen Webdienst zu übertragen, können Sie die Eigenschaft Anmeldeinformationen des Webdienst-Proxyservers auf CredentialCache setzen.DefaultCredentials wie folgt.

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

Sie können auch wie folgt eine bestimmte Reihe von Anmeldeinformationen verwenden:

CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Webdienst-URL
          "Negotiate",         // Kerberos oder NTLM
           new NetworkCredential(userName, password, domain));
proxy.Credentials = cache;

Wenn explizite Anmeldeinformationen festgelegt werden müssen, sollten diese nicht hartcodiert oder in Klartext gespeichert werden. Verschlüsseln Sie Kontoanmeldeinformationen mithilfe von DPAPI und speichern Sie die verschlüsselten Daten in Web.config in einem Element <appSettings> oder unterhalb eines eingeschränkten Registrierungsschlüssels.

Weitere Informationen zur Authentifizierung auf Plattformebene finden Sie im Abschnitt "Web Services Security" in "Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" unter https://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true.

Authentifizierung auf Meldungsebene

WSE kann verwendet werden, um eine Authentifizierungslösung auf Meldungsebene zu implementieren, die den Webdienstsicherheitsstandards entspricht. Dadurch können Sie Authentifizierungstokens mithilfe von SOAP-Headern übertragen.

Hinweis: Wenn zwei Parteien sich auf die Verwendung von Webdienstsicherheit einigen, müssen sie auch das genaue Format des Authentifizierungtokens gemeinsam festlegen.

Folgende von WSE unterstützte Arten von Authentifizierungstokens können verwendet werden:

  • Benutzername und Kennwort

  • Kerberos-Tickets

  • X.509-Zertifikate

Benutzername und Kennwort

Benutzernamen und Kennwörter können im SOAP-Header als Anmeldeinformationen gesendet werden. Da diese jedoch als Klartext gesendet werden, sollten Sie diese Methode nur in Verbindung mit SSL verwenden, da die Gefahr eines Abhörens des Netzwerks besteht. Die Anmeldeinformationen werden wie folgt im SOAP-Header als Teil des Elements <Security> gesendet.

<wsse:Security
         xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/12/secext">
  <wsse:UsernameToken>
    <wsse:Username>Robert</wsse:Username> 
    <wsse:Password>IhrStarke5Kennwort</wsse:Password>
   </wsse:UsernameToken>
</wsse:Security>

Benutzername- und Kennwort-Digest

Anstelle eines Kennworts im Klartext kann ein Kennwort-Digest gesendet werden. Bei dem Digest handelt es sich um einen Base64-verschlüsselten SHA1-Hashwert des UTF8-verschlüsselten Kennworts. Dennoch können die Daten, sofern kein sicherer Kanal verwendet wird, von Angreifern mithilfe von Netzwerküberwachungssoftware abgefangen und wiederverwendet werden, um Zugriff auf Ihren Webdienst zu erhalten. Um dies zu verhindern, kann ein Nonce und ein Erstellungstimestamp mit dem Digest kombiniert werden.

Benutzername- und Kennwort-Digest mit Nonce und Timestamp

Dadurch wird der Digest wie folgt zu einem SHA1-Hash eines Noncewerts, eines Erstellungstimestamp und des Kennworts.

digest = SHA1(nonce + creation timestamp + password)

Hierbei muss der Webdienst über eine Tabelle der Noncewerte verfügen und sämtliche Meldungen ablehnen, die einen doppelten Noncewert enthalten. Zwar schützt diese Methode das Kennwort und bietet eine Grundlage gegen Wiedergabeangriffe, sie wirft jedoch Probleme bei der Synchronisation des Computertaktes zwischen dem Kunden und dem Anbieter auf, wenn ein Ablaufzeitpunkt berechnet wird. Auch bietet sie keinen Schutz, wenn ein Angreifer die Meldung abfängt, den Noncewert ändert und anschließend die Meldung auf dem Webdienst wiedergibt. Um dies zu verhindern, muss die Meldung digital signiert werden. Mit WSE kann eine Meldung mithilfe eines benutzerdefinierten Tokens oder eines X.509-Zertifikats signiert werden. Dies bietet Fälschungssicherheit und Authentifizierung beruhend auf einem Schlüsselpaar mit öffentlichem und privatem Schlüssel.

Kerberos-Tickets

Sicherheitstokens mit einem Kerberos-Ticket können wie folgt gesendet werden.

<wsse:Security
         xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/12/secext">
  <wsse:BinarySecurityToken
           ValueType="wsse:Kerberosv5ST"
           EncodingType="wsse:Base64Binary">
    U87GGH91TT ...
  </wsse:BinarySecurityToken>
</wsse:Security>
X.509-Zertifikate

Eine Authentifizierung kann auch mithilfe eines X.509-Zertifikats als Authentifizierungstoken durchgeführt werden.

<wsse:Security
         xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/12/secext">
  <wsse:BinarySecurityToken
          ValueType="wsse:X509v3"
          EncodingType="wsse:Base64Binary">
     Hg6GHjis1 ...        
  </wsse:BinarySecurityToken>
</wsse:Security>

Weitere Informationen über diese Methoden finden Sie in den Beispielen, die mit WSE geliefert werden.

Authentifizierung auf Anwendungsebene

Sie können für Ihre Anwendung mithilfe der SOAP-Header eine eigene benutzerdefinierte Authentifizierung entwerfen und erstellen. Überprüfen Sie zuvor die von der Plattform und WSE bereitgestellten Funktionen auf deren Verwendbarkeit. Wenn eine benutzerdefinierte Authentifizierung mithilfe von Kryptografie verwendet werden muss, sollten die Standardverschlüsselungalgorithmen des System.Security.Cryptography-Namespace verwendet werden.

 

Autorisierung

Im Anschluss an die Authentifizierung können Benutzer basierend auf deren Identität und Rollenzugehörigkeit auf einen Teil der vom Webdienst angebotenen Funktionen beschränkt werden. Der Zugriff auf Dienstendpunkte (auf der .asmx-Dateiebene), einzelne Webmethoden oder bestimmte Funktionen innerhalb der Webmethoden kann eingeschränkt werden.

Webdienstendpunkt-Autorisierung

Wenn Ihr Webdienst für integrierte Windows-Authentifizierung konfiguriert ist, können Sie NTFS-Berechtigungen für die Webdienstdateien (.asmx) konfigurieren, um basierend auf dem Sicherheitskontext des ursprünglichen Benutzers den Zugriff zu steuern. Die Autorisierung wird vom ASP.NET-Modul FileAuthorizationModule durchgeführt und bedarf keines Identitätswechsels.

Sie können das ASP.NET-Modul UrlAuthorizationModule unabhängig vom Authentifizierungstyp zur Steuerung des Zugriffs auf Webdienstdateien (.asmx) verwenden. Fügen Sie zum Konfigurieren dem Element <authorization> in Machine.config oder Web.config die Elemente <allow> und <deny> hinzu.

Weitere Informationen zu beiden Autorisierungsarten finden Sie im Abschnitt "Autorisierung" in Modul 19, "Schützen der ASP.NET-Anwendung und der -Webdienste".

Autorisierung von Webmethoden

Um den Zugriff auf einzelne Webmethoden anhand der Identität oder Rollenzugehörigkeit des Benutzers zu steuern, können deklarative Anforderungen für Berechtigungsprinzipale verwendet werden. Die Identität und Rollenzugehörigkeit des Benutzers wird durch das der aktuellen Webabfrage zugeordnete Prinzipalobjekt verwaltet (Zugriff über HttpContext.User.)

[PrincipalPermission(SecurityAction.Demand, Role=@"Manager")]
[WebMethod]
public string QueryEmployeeDetails(string empID)
{
}

Weitere Informationen zu Anforderungen von Prinzipalberechtigungen finden Sie im Abschnitt "Autorisierung" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente".

Programmautorisierung

Sie können imperative Berechtigungsüberprüfungen oder explizite Rollenüberpfüfungen verwenden, indem Sie innerhalb Ihrer Webmethoden für eine feinstufige Autorisiungslogik IPrincipal.IsInRole aufrufen.

// Dies setzt eine nicht-Windows-Authentifizierung voraus. Bei der Windows-Authentifizierung
// Das Benutzerobjekt in ein WindowsPrincipal umwandeln und Windows-Gruppen als
// Rollennamen verwenden
GenericPrincipal user = User as GenericPrincipal;
if (null != user)
{
  if ( user.IsInRole(@"Manager") )
  {
    // Der Benutzer ist autorisiert, Verwaltungsfunktionen auszuführen
  }
}

 

Vertrauliche Daten

Die Risiken eines Abhörens des Netzwerks oder der Offenlegung von Daten an Zwischenanwendungsknoten müssen bedacht werden, wenn Ihre Webdienstabfrage- oder -antwortmeldungen vertrauliche Anwendungsdaten übertragen, beispielsweise Kreditkartennummern, Mitarbeiterinformationen, usw..

In einer geschlossenen Umgebung, in der Sie beide Endpunkte steuern, können Sie SSL oder IPSec für eine Verschlüsselung auf Transportebene verwenden. In anderen Umgebungen, in denen Meldungen über Zwischenanwendungsknoten geroutet werden, ist eine Lösung auf Meldungsebene erforderlich. Der Webdienstsicherheitsstandard definiert einen Vertraulichkeitsdienst, der auf dem W3C-XML-Verschlüsselungsstandard (World Wide Web Consortium) beruht, und ermöglicht eine Verschlüsselung einiger oder aller SOAP-Meldungen vor der Übertragung.

XML-Verschlüsselung

Eine SOAP-Meldung kann auf drei Arten vollständig oder teilweise verschlüsselt werden:

  • Asymmetrische Verschlüsselung mithilfe von X.509-Zertifikaten

  • Symmetrische Verschlüsselung mithilfe gemeinsamer Schlüssel

  • Symmetrische Verschlüsselung mithilfe benutzerdefinierter Binärtokens

Asymmetrische Verschlüsselung mithilfe von X.509-Zertifikaten

Hierbei verwendet der Kunde den öffentlichen Schlüssel eines X.509-Zertifikats für die Verschlüsselung der SOAP-Meldung. Diese kann dann lediglich von einem Dienst entschlüsselt werden, der über den privaten Schlüssel verfügt.

Der Webdienst muss über Zugriff auf den zugeordneten privaten Schlüssel verfügen. In der Standardeinstellung sucht WSE im Speicher des lokalen Computers nach X.509-Zertifikaten. Sie können in Web.config mithilfe des Konfigurationselements <x509> wie folgt den Speicherort auf den aktuellen Benutzerspeicher ändern.

<configuration>
  <microsoft.web.services>
    <security>
      <x509 storeLocation="CurrentUser" />
   </security>
  </microsoft.web.services>
</configuration>

Wenn der Benutzerspeicher verwendet wird, muss das Benutzerprofil des Prozesskontos des Webdienstes geladen werden. Wird der Webdienst mithilfe des lokalen ASPNET-Standardkonto mit den geringsten Berechtigungen ausgeführt, wird von .NET Framework Version 1.1 das Benutzerprofil des Kontos geladen, womit auf den Benutzerschlüsselspeicher zugegriffen werden kann.

Bei Webdiensten, die mit Version 1.0 des .NET Framework erstellt wurden, wird das ASPNET-Benutzerprofil nicht geladen. In diesem Szenario verfügen Sie über zwei Optionen.

  • Führen Sie den Webdienst mithilfe eines benutzerdefinierten Kontos mit den geringsten Berechtigungen aus, das bereits interaktiv am Webserver angemeldet wurde, um ein Benutzerprofil zu erstellen.

  • Speichern Sie den Schlüssel auf dem lokalen Computer und erteilen Sie dem Prozesskonto Ihres Webdienstes Zugriff. Bei Windows 2000 handelt es sich hierbei standardmäßig um das ASPNET-Konto. Bei Windows Server 2003 handelt es sich um das Netzwerkdienstkonto.

    Erteilen Sie den Zugriff mithilfe des Windows Explorer und konfigurieren Sie für folgenden Ordner eine Zugriffssteuerungsliste, die dem Prozesskonto des Webdienstes Vollzugriff gewährt.

    \Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\
                                          Microsoft\Crypto\RSA\MachineKeys

Weitere Informationen finden Sie in der WSE-Dokumentation in den Abschnitten "Managing X.509 Certificates", "Encrypting a SOAP Message Using an X.509 Certificate" und "Decrypting a SOAP Message Using an X.509 Certificate".

Symmetrische Verschlüsselung mithilfe gemeinsamer Schlüssel

Bei der symmetrischen Verschlüsselung verwenden Webdienst und Kunde einen geheimen Schlüssel zum Ver- und Entschlüsseln der SOAP-Meldung. Dies ist schneller als eine asymmetrische Verschlüsselung, obwohl Kunde und Dienstanbieter für den gemeinsamen Schlüssel einige Out-of-Band-Verfahren verwenden müssen.

Weitere Informationen finden Sie in der WSE-Dokumentation in den Abschnitten "Encrypting a SOAP Message Using a Shared Key" und "Decrypting a SOAP Message Using a Shared Key".

Symmetrische Verschlüsselung mithilfe benutzerdefinierter Binärtokens

WSE kann außerdem verwendet werden, um einen benutzerdefinierten Binärtoken zu definieren, mit dem die für die Ver- und Entschlüsselung von Meldungen verwendeten benutzerdefinierten Sicherheitsanmeldeinformationen gekapselt werden. Der Code muss zwei Klassen enthalten. Für die Absenderklasse muss auf die Klasse BinarySecurityToken zurückgegriffen werden, um die benutzerdefinierten Sicherheitsanmeldinformationen zu kapseln und die Meldung zu verschlüsseln. Für die Empfängerklasse ist die Klasse DecryptionkeyProvider zu nutzen, um den Schlüssel für die Entschlüsselung der Meldung zu erhalten.

Weitere Informationen finden Sie in der WSE-Dokumentation in den Abschnitten "Encrypting a SOAP Message Using a Custom Binary Security Token" und "Decrypting a SOAP Message Using a Custom Binary Security Token".

Verschlüsseln von Teilen einer Meldung

In der Standardeinstellung verschlüsselt WSE zwar den vollständigen SOAP-Nachrichtentext, aber keinerlei SOAP-Headerinformationen. WSE kann jedoch auch für das Ver- und Entschlüsseln von Teilen einer Meldung verwendet werden.

Weitere Informationen finden Sie in der WSE-Dokumentation im Abschnitt "Specifying the Parts of a SOAP Message that are Signed or Encrypted".

 

Parametermanipulation

Parametermanipulation im Zusammenhang mit Webdiensten bezieht sich auf die Gefahr, dass ein Angreifer den Meldungsinhalt ändert, während die Meldungsanforderung oder -antwort zwischen dem Dienst und dem Kunden übertragen wird.

Begegnen Sie diesem Risiko, indem Sie eine SOAP-Meldung digital signieren, um dem Empfänger zu ermöglichen, kryptografisch zu überprüfen, ob die Meldung im Anschluss an die Signatur geändert wurde. Weitere Informationen finden Sie in der WSE-Dokumentation im Abschnitt "Digitally Signing a SOAP Message".

 

Ausnahmeverwaltung

An den Kunden zurückgegebene Ausnahmedetails sollten lediglich minimale Informationen enthalten und keinerlei interne Implementierungsdetails offen legen. Betrachten Sie beispielsweise folgende, zum Kunden gelangte Systemausnahme.

System.Exception: User not in managers role
   at EmployeeService.employee.GiveBonus(Int32 empID, Int32 percentage) in 
c:\inetpub\wwwroot\employeesystem\employee.asmx.cs:line 207

Diese Ausnahmedetails legen dem Dienstkunden die Verzeichnisstruktur und andere Details offen. Diese Informationen können von einem bösartigen Benutzer für ein Footprinting des virtuellen Verzeichnispfads und somit für weitere Angriffe verwendet werden.

Webdienste können drei Ausnahmearten erzeugen:

  • SoapException objects.
    Diese können von der CLR oder vom Implementierungscode Ihrer Webmethode erstellt werden.

  • SoapHeaderException -Objekte
    Diese werden automatisch erstellt, wenn der Kunde eine SOAP-Anforderung sendet, die der Dienst nicht ordnungsgemäß verarbeiten kann.

  • Exception-Objekte
    Ein Webdienst kann eine benutzerdefinierte Ausnahmeart erstellen, die sich aus der System.Exception ableitet. Die genaue Ausnahmeart ist spezifisch für die Fehlerbedingung. So kann es sich beispielsweise um eine der .NET Framework-Standardausnahmearten wie etwa DivideByZeroException oder ArgumentOutOfRangeException handeln.

Unabhängig von der Ausnahmeart werden die Ausnahmedetails mithilfe des SOAP-Standardelements <Fault> an den Client übertragen. Mithilfe von ASP.NET erstellte Clients und Webdienste verarbeiten das Element <Fault> nicht direkt, sondern behandeln einheitlich SoapException-Objekte. Dadurch kann der Client try-Blöcke einrichten, die SoapException-Objekte abfangen.

Hinweis: Beim Erzeugen einer SoapException in einem benutzerdefinierten HTTP-Modul wird diese nicht automatisch als SOAP-<Fault> serialisert. In diesem Fall muss SOAP-<Fault> manuell erstellt werden.

Verwenden von SoapExceptions

Im folgenden Codebeispiel wird eine einfache "WebMethod" implementiert, bei der die Überprüfung der Anwendungslogik fehlschlägt und daher eine Ausnahme erzeugt wird. Es werden nur minimale Fehlerinformationen an den Client gesendet. In diesem Beispiel wird dem Client ein Verweis an einen Helpdesk bereitgestellt, über den der Kundendienst zu erreichen ist. Auf dem Webserver wird eine genaue Fehlerbeschreibung für den Helpdesk protokolliert, die bei der Problemdiagnose hilfreich ist.

using System.Xml;
using System.Security.Principal;

[WebMethod]
public void GiveBonus(int empID, int percentage)
{
  // Lediglich Manager können einen Bonus gewähren
  // In diesem Beispiel wird Windows-Authentifizierung verwendet.
  WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
  if( wp.IsInRole(@"Domain\Managers")) 
  {
     // Benutzer ist autorisiert, einen Bonus zu gewähren
     . . .
  }
  else
  {
    // Protokollieren der Fehlerdetails auf dem Server. Zum Beispiel:
    //    "DOMAIN\Robert versuchte Bonus an Employee Id 345667 zu geben;
    //     Zugriff verweigert da DOMAIN\Robert kein Manager ist".
    // Hinweis: Der Benutzername ist in wp.Identity.Name verfügbar

    // Geben Sie mithilfe einer SoapException minimale Fehlerinformationen an den Client zurück
    XmlDocument doc = new XmlDocument();
    XmlNode detail = doc.CreateNode(XmlNodeType.Element,
                                    SoapException.DetailElementName.Name,
                                    SoapException.DetailElementName.Namespace);
    // Dies ist der ausführliche Teil der Ausnahme
    detail.InnerText = "User not authorized to perform requested operation";
    throw new SoapException("Message string from your Web service", 
                            SoapException.ServerFaultCode, 
                            Context.Request.Url.AbsoluteUri, detail, null );
  } 
}

Es folgt der Kundencode, der potenzielle SoapExceptions behandelt:

try
{
  EmployeeService service = new EmployeeService();
  Service.GiveBonus(empID,percentage);
}
catch (System.Web.Services.Protocols.SoapException se)
{
   // Extrahieren der Kundenmeldung von se.Detail.InnerText
   Console.WriteLine("Server threw a soap exception" + se.Detail.InnerText );
}

Fehlerbehandlung auf der Anwendungsebene in Global.asax

ASP.NET-Webanwendungen behandeln gewöhnlich Ausnahmen auf Anwendungsebene, denen es möglich ist, eine Methodengrenze im Ereignishandler Application_Error in Global.asax zu verlassen. Diese Funktion ist für Webdienste nicht verfügbar, da der HttpHandler des Webdienstes die Ausnahme abfängt, bevor diese andere Handler erreicht.

Ist eine Ausnahmebehandlung auf Anwendungsebene erforderlich, ist eine benutzerdefinierte SOAP-Erweiterung zu erstellen. Weitere Informationen finden Sie im MSDN-Artikel "Altering the SOAP Message using SOAP Extensions" im Abschnitt "Building Applications" des .NET Framework-SDK unter https://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&DisplayLang=en.

 

Überwachen und Protokollieren

Bei Webdiensten können Aktivitätsdetails und Transaktionen entweder mithilfe einer Funktion auf Plattformebene oder eines benutzerdefinierten Codes in der Webmethodenimplementierung überwacht und protokolliert werden.

Sie können einen Code entwickeln, der die Klasse System.Diagnostics.EventLog verwendet, um Aktionen im Windows-Ereignisprotokoll zu protokollieren. Die Berechtigungsanforderungen und Techniken für die Verwendung dieser Klasse von einem Webdienst sind die gleichen wie bei einer Webanwendung. Weitere Informationen finden Sie im Abschnitt "Überwachen und Protokollieren" in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente".

 

Überlegungen zu Proxy-Einstellungen

Wenn Sie WSDL verwenden, um automatisch eine Proxyklasse für die Kommunikation mit einem Webdienst zu erstellen, sollten Sie den erzeugten Code und die Dienstendpunkte überprüfen, um sicherzustellen, dass Sie mit dem gewünschten Webdienst und nicht mit einem gefälschten Dienst kommunizieren. Wenn die WSDL-Dateien auf einem Remoteserver ungenügend geschützt sind, kann ein bösartiger Benutzer die Dateien manipulieren und die Endpunktadressen ändern, was den erzeugten Proxycode beeinflussen kann.

Überprüfen Sie insbesondere das Element <soap:address> im der .wsdl-Datei, und stellen Sie sicher, dass es auf den erwarteten Speicherort verweist. Wenn Sie Visual Studio .NET verwenden, um mithilfe des Dialogfelds Webreferenz hinzufügen eine Webreferenz hinzuzufügen, blättern Sie nach unten, und überprüfen Sie die Dienstendpunkte.

Überprüfen Sie unabhängig davon, ob Sie mithilfe von Visual Studio.NET eine Webreferenz hinzugefügt oder mit Wsdl.exe den Proxycode manuell erstellt haben, abschließend den Proxycode genau, und suchen Sie nach verdächtigem Code.

Hinweis: Sie können die Einstellung URL-Verhalten des Webdienst-Proxyservers auf Dynamisch setzen, um die Endpunktadressen in Web.config festlegen zu können.

 

Überlegungen zur Codezugriffssicherheit

Die Codezugriffssicherheit kann den Zugriff auf Ressourcen und die Ausführbarkeit von Verfahren durch den Webdienstcode einschränken. Ein ASP.NET-Webdienst unterliegt der ASP.NET-Richtlinie für Codezugriffssicherheits, die vom Element <trust> des Webdienstes konfiguriert wird.

Einem .NET Framework-Kundencode, der einen Webdienst aufruft, muss von der Richtlinie für die Codezugriffssicherheit die WebPermission erteilt werden. Der genaue Status der WebPermission legt den aufrufbaren Bereich des Webdienstes fest. So kann Ihr Code beispielweise auf das Aufrufen lokaler Webdienste oder solchen auf bestimmten Servern begrenzt werden.

Wenn der Kundencode als vollständig vertrauenswürdig gilt, wird ihm eine uneingeschränkte WebPermission gewährt, mit der Sie sämtliche Webdienste aufrufen können. Kundencode mit lediglich teilweiser Vertrauenswürdigkeit unterliegt folgenden Einschränkungen:

  • Wenn ein Webdienst von einer nur teilweise vertrauenswürdigen Webanwendung aufgerufen wird, kann in der Standardeinstellung lediglich auf lokale Webdienste zugegriffen werden.

  • Kundencodes, die WSE-Klassen verwenden, sind als vollständig vertrauenswürdig einzustufen. Wenn beispielsweise die Proxyklassen Ihres Webdienstes von Microsoft.Web.Services.WebServicesClientProtocol stammen, die von den WSE bereitgestellt wird, ist eine vollständige Vertrauenswürdigkeit erforderlich. Um WSE von einer teilweise vertrauenswürdigen Webanwendung verwenden zu können, müssen Aufrufe an den Webdienst kontrolliert ausgeführt werden.

Weitere Informationen zum Aufrufen von Webdiensten von teilweise vertrauenswürdigen Webanwendungen finden Sie in Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET". Weitere Informationen zu WebPermission, finden Sie im Abschnitt "Webdienste" in Modul, 8 "Codezugriffssicherheit in der Praxis".

 

Überlegungen zur Bereitstellung

Die Bandbreite an verfügbaren Sicherheitsoptionen ist hauptsächlich von den Bereitstellungsszenarien abhängig, die Ihre Webdienste abdecken sollen. Wenn Sie Anwendungen erstellen, die in einem Intranet auf Webdienste zugreifen, steht Ihnen die größte Bandbreite an Sicherheitoptionen und -techniken zur Verfügung. Wenn Ihr Webdienst jedoch über das Internet öffentlich zugänglich ist, sind Ihre Optionen weitaus limitierter. In diesem Abschnitt finden Sie die Auswirkungen verschiedener Bereitstellungsszenarien auf die Anwendbarkeit der verschiedenen in diesem Modul beschriebenen Sicherungsansätze für Webdienste.

Intranetbereitstellung

Da Sie die Kundenanwendung, den Dienst und die Plattform steuern, bieten Intranets in der Regel die größte Bandbreite an verfügbaren Optionen für den Schutz von Webdiensten.

In einem Intranetszenario können Sie gewöhnlich aus sämtlichen Optionen für die Authentifizierung und sichere Kommunikation wählen. So kann beispielsweise die Windows-Authentifizierung verwendet werden, wenn sich Kunde und Dienst auf derselben oder auf vertrauenswürdigen Domänen befinden. Es kann festgelegt werden, dass die Entwickler von Clientanwendungen die Eigenschaften für Anmeldeinformationen auf dem Clientproxyserver so einstellen, dass die Anmeldeinformationen des Kunden an den Webdienst übertragen werden.

Die Intranetkommunikation findet häufig relativ sicher über ein privates Netzwerk statt. Wenn dies nicht ausreicht, kann der Datenverkehr mithilfe von SSL verschlüsselt werden. Sicherheit auf Meldungsebene gewährleisten Sie, indem WSE sowohl auf dem Client als auch auf dem Server installiert wird, um die Sicherheit an beiden Enden transparent für die Anwendung zu verwalten. WSE unterstützt Authentifizierung, digitale Signaturen und Verschlüsselung.

Extranetbereitstellung

In einem Extranetszenario muss der Webdienst möglicherweise einer begrenzten Anzahl von Partnern über das Internet offen gelegt werden. Der Benutzerkreis ist bekannt, absehbar und verwendet möglicherweise verwaltete Clientanwendungen, obwohl die Benutzer aus separaten, unabhängigen Umgebungen kommen. In diesem Fall ist ein Authentifizierungsverfahren erforderlich, dass sich für beide Parteien eignet, und das nicht von vertrauenswürdigen Domänen abhängig ist.

Wenn Konteninformationen für beide Seiten verfügbar sind, kann eine Standardauthentifizierung verwendet werden. In diesem Fall müssen die Anmeldeinformationen mithilfe von SSL geschützt werden.

Hinweis: SSL schützt Anmeldeinformationen lediglich in einem Netzwerk. Es ist jedoch kein Schutz vorhanden, wenn ein Angreifer erfolgreich ein Proxytool (etwa sslproxy) lokal auf dem Clientcomputer installiert, um den Aufruf abzufangen, bevor dieser über SSL an den Webdienst weitergeleitet wird.

Wahlweise kann für ein Extranet die IIS-Clientzertifikatauthentifizierung verwendet werden, anstatt explizite Anmeldeinformationen zu übertragen. Hierbei muss die aufrufende Anwendung mit dem Aufruf ein gültiges Zertifikat vorweisen. Der Webdienst verwendet das Zertifikat zur Authentifizierung des Benutzers und zur Autorisierung des Verfahrens. Weitere Informationen finden Sie im Abschnitt "Extranet Security" des MSDN-Artikels "Building Secure ASP.NET Applications" unter https://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch06.asp.

Internetbereitstellung

Wenn Ihr Webdienst einem großen Kreis von Internetkunden zugänglich und daher eine Authentifizierung erforderlich ist, verringert sich die Bandbreite verfügbarer Optionen. Die verschiedenen Formen der Authentifizierung auf Plattformebene sind wenig sinnvoll, da die Kunden nicht über ordnungsgemäße Domänenkonten verfügen, denen die Anmeldeinformationen zugeordnet werden könnten. Die Verwendung der IIS-Clientzertifikatsauthentifizierung oder einer auf Transportebene (SSL) ist ebenfalls problematisch, wenn eine Vielzahl an Clientzertifikaten dem Ziel-IIS-Webserver (oder dem vorgeschalteten ISA-Server) bekannt gegeben werden muss. Daher bietet sich die Authentifizierung auf Meldungs- und Anwendungsebene an. Die vom Dienstkunden in Form von Benutzernamen, Kennwörtern, Zertifikaten, Kerberos-Tickets oder benutzerdefinierten Tokens übertragenen Anmeldeinformationen können von der Infrastruktur des Webdienstes (WSE) oder als Programm innerhalb des Zieldienstes transparent überprüft werden. Clientzertifikate sind schwer zu skalieren. Die Schlüsselverwaltung (Ausstellen und Sperren) wird problematisch. Darüber hinaus ist eine zertifikatbasierte Authentifizierung ressourcenintensiv und daher bei einer großen Menge an Clients anfällig für Skalierbarkeitsprobleme.

SSL bietet in der Regel eine Verschlüsselung des Netzwerkverkehrs (nur Zertifikate auf dem Server), kann jedoch durch Verschlüsselung auf Meldungsebene ergänzt werden.

Die Verwendung von Clientzertifikaten ist zwar aus Sicherheitserwägungen vorteilhaft, wird jedoch bei einer großen Anzahl von Benutzern problematisch. Die Zertifikate müssen sorgfältig verwaltet werden. Auch muss unter anderem deren Erneuerung, Ausstellung und Übermittlung an Clients bedacht werden. Ein weiteres potenzielles Problem in Internetszenarien ist die allgemeine Skalierbarkeit der Lösung aufgrund der Verarbeitungslast oder der Ver-/Entschlüsselung und Zertifikatsüberprüfung für einen groß angelegten Webdienst mit erheblicher Arbeitslast.

 

Zusammenfassung

Webdienstsicherheit ist der entstehende Standard für die Sicherheit von Webdiensten. Die Spezifikation legt mithilfe der SOAP-Header Optionen für die Authentifizierung durch das standardmäßige Übertragen von Sicherheitstokens fest. Zu den Tokens zählen Benutzernamen und Kennwörter, Kerberos-Tickets, X.509-Zertifikate oder benutzerdefinierte Tokens. Webdienstsicherheit behandelt außerdem die Vertraulichkeit von Meldungen und Integritätsprobleme. Sie können Meldungen vollständig oder teilweise verschlüsseln und digital signieren, um Integrität und Vertraulichkeit sicherzustellen.

In Intranetszenarien, in denen Endpunkte gesteuert werden, können Sicherheitsoptionen auf Plattformebene (etwa die Windows-Authentifizierung) verwendet werden. In komplexeren Szenarien ohne Steuerung beider Endpunkte, bei denen Meldungen über Zwischenanwendungsknoten geroutet werden, sind Lösungen auf Meldungsebene erforderlich. Im folgenden Abschnitt "Zusätzliche Referenzen" finden Sie eine Liste von Websites, auf denen Sie Informationen zum entstehenden Webdienstsicherheitsstandard und dem entsprechenden WSE Tool Kit finden, mit dem Sie Lösungen erstellen können, die diesem und anderen Webdienststandards entsprechen.

 

Weitere Quellen

Weitere Informationen finden Sie in den folgenden Quellen.