Sicherheitsaspekte bei Web-Services

Wenn Sie Web Services Security konfigurieren, müssen Sie alles daran setzen, sicherzustellen, dass das Ergebnis vor der Vielzahl an Angriffsmöglichkeiten auf die Sicherheit geschützt ist. Dieser Artikel enthält einige Informationen zu den möglichen Sicherheitsproblemen, die sich beim Absichern von Web-Services stellen.

Wenn Sie in WebSphere Application Server die Integrität, die Vertraulichkeit und die zugeordneten Tokens innerhalb einer SOAP-Nachricht aktivieren, ist die Sicherheit nicht garantiert. Diese Liste der Sicherheitsprobleme ist nicht vollständig. Sie müssen für Ihre Umgebung eine eigene Sicherheitsanalyse durchführen.

  • Die Aktualität der Nachricht sicherstellen
    Nachrichtenaktualität sicherstellen bedeutet, die Ressourcen vor einer Attacke durch Nachrichtenaufzeichnung und -wiederholung zu schützen, bei dem die Nachricht abgefangen und dann erneut gesendet wird. Digitale Signaturen alleine sind kein ausreichender Schutz vor einer Attacke durch Nachrichtenaufzeichnung und -wiederholung, weil auch eine signierte Nachricht abgefangen und erneut gesendet werden kann. Stattdessen wird empfohlen, dass Sie den Nachrichtenempfängern die Möglichkeit geben, solche Attacken zu erkennen, wenn die Nachrichten über ein offenes Netz ausgetauscht werden. Sie können dazu die folgenden Elemente verwenden, die in den Spezifikationen zu Web Services Security beschrieben sind:
    Timestamp
    Mit Hilfe des Zeitmarkenelements (timestamp) können Sie die Nachrichten verfolgen und so feststellen, ob bereits gesendete Nachrichten wiederholt werden. Die Spezifikation WS-Security 2004 empfiehlt, Zeitmarken für eine bestimmte Zeit zwischenzuspeichern. Als Richtschnur können Sie eine Mindestzeit von fünf Minuten verwenden, um Nachrichtenwiederholungen zu erkennen. Die Nachrichten, die eine abgelaufene Zeitmarke enthalten, werden zurückgewiesen.
    Nonce
    Ein Nonce ist ein untergeordnetes Element des Elements <UsernameToken> im Benutzernamenstokenprofil. Weil jedes Nonce-Element einen eindeutigen Wert hat, können die Empfänger Attacken durch Nachrichtenaufzeichnung und -wiederholung relativ leicht feststellen.
    Fehler vermeiden Fehler vermeiden: Um mit Hilfe von Zeitmarken (Timestamp) die bestmögliche Sicherheit vor Attacken durch Nachrichtenaufzeichnung und -wiederholung zu erzielen, müssen sowohl das Zeitmarkenelement als auch das Nonce-Element signiert sein. Andernfalls können diese Elemente leicht geändert werden und somit Attacken durch Nachrichtenaufzeichnung und -wiederholung nicht verhindern. gotcha

    Weitere Informationen zum Zeitmarkenelement finden Sie unter Timestamp.

    In WebSphere Application Server wird die Richtlinienzusicherung IncludeTimestamp durchgesetzt. Viele Service-Provider setzen zwar voraus, dass das Element <wsu:Timestamp> in der Anforderung enthalten ist, senden jedoch keines in der Antwort. Es ist auch möglich, dass in der Antwort überhaupt kein Sicherheitsheader (Security) enthalten ist und schon gar nicht eine Zeitmarke (Timestamp). Auf einem Client tritt der folgende Fehler auf, wenn IncludeTimestamp in der Richtlinie enthalten ist, aber keine Zeitmarke (Timestamp) in der Antwort zurückgegeben wird:
    CWWSS5730E: Die erforderliche Zeitmarke wurde nicht gefunden. 
    Zum Beheben des Problems konfigurieren Sie entweder den Service-Provider so, dass er eine Zeitmarke sendet, oder konfigurieren Sie den Client so, dass er keine Zeitmarke erfordert, indem Sie die angepasste Eigenschaft com.ibm.wsspi.wssecurity.consumer.timestampRequired in den WS-Security-Richtlinienbindungen auf false setzen. Weitere Informationen finden Sie unter Angepasste Eigenschaften für Web Services Security.
  • Verwenden Sie die digitale XML-Signatur und die XML-Verschlüsselung ordnungsgemäß, um eine potenzielle Lücke im Sicherheitssystem zu vermeiden.

    Die Spezifikation "Web Services Security 2004" legt fest, wie die digitale XML-Signatur und die XML-Verschlüsselung in SOAP-Headern (Simple Object Access Protocol) verwendet werden müssen. Die Benutzer müssen daher die digitale XML-Signatur und die XML-Verschlüsselung im Kontext anderer Sicherheitsmechanismen betrachten und ihre möglichen Sicherheitsrisiken kennen. Bei der digitalen XML-Signatur müssen Sie sich darüber im Klaren sein, welche Folgen sich aus der Verwendung digitaler Signaturen im Allgemeinen und der digitalen XML-Signatur im Besonderen für die Sicherheit ergeben. Wenn Sie eine Anwendung mittels einer digitalen Signatur sichern, müssen Sie zusätzliche Technologien integrieren, wie die Gültigkeitsprüfung des Zertifikats basierend auf PKI (Public Key Infrastructure). Für die XML-Verschlüsselung kann die Kombination aus digitaler Signatur und Verschlüsselung für ein allgemeines Datenelement Sicherheitsrisiken bergen. Werden beispielsweise digital signierte Daten verschlüsselt, wird die digitale Signatur eventuell in Klartext angeben, sodass die Nachricht Angriffen ausgesetzt ist, bei denen versucht wird, Klartext abzufragen. Als allgemeine Vorgehensweise wird empfohlen, beim Verschlüssen der Daten auch alle Auszüge (Digest) oder Signaturen für die Daten zu verschlüsseln. Weitere Informationen finden Sie im Artikel http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt.

  • Die Integrität der Sicherheitstoken schützen

    Es besteht die Möglichkeit, dass ein Angriff mit Tokenaustausch erfolgt. In einem solchen Szenario wird die digitale Signatur mit einem Schlüssel verifiziert, der häufig aus einem Sicherheitstoken abgeleitet und in einer Nachricht enthalten ist. Wird dieser Token ausgetauscht, kann ein Empfänger, anders als von Ihnen erwartet, die Nachricht basierend auf dem ausgetauschten Schlüssel akzeptieren. Eine mögliche Lösung dieses Problems besteht darin, das Sicherheitstoken (oder die eindeutigen Identifizierungsdaten, aus denen der Signierschlüssel abgeleitet wird,) zusammen mit den signierten Daten zu signieren. In einigen Fällen ist das Token, das von einer anerkannten Zertifizierungsstelle ausgegeben wird, signiert. In diesem Fall könnte es kein Integritätsproblem geben. Da sich die Anwendungssemantik und die Umgebung im Lauf der Zeit jedoch ändern können, sollten Sie einen solchen Angriff am besten von vornherein verhindern. Sie müssen die Risikobewertung ausgehend von der implementierten Umgebung ermitteln.

  • Das Zertifikat verifizieren, um die Prüfung des Zertifikatspfades und die Zertifikatswiderrufsliste zu verwenden

    Es wird empfohlen, die Authentizität oder Gültigkeit der Tokenidentität, die für die digitale Signatur verwendet wird, zu verifizieren. Insbesondere für ein X.509-Token bedeutet dies, dass der Zertifikatspfad verifiziert und eine Zertifikatswiderrufsliste (Certificate Revocation List) verwendet wird. In der Implementierung von Web Services Security in WebSphere Application Server ab Version 6 wird das Zertifikat vom Element <TokenConsumer> überprüft. WebSphere Application Server stellt eine Standardimplementierung für das X.509-Zertifikat bereit, in der die Java™-CertPath-Bibliothek zur Verifizierung und Validierung des Zertifikats verwendet wird. In dieser Implementierung existiert kein explizites Konzept einer CRL. Stattdessen werden ordnungsgemäße Stammzertifikate und Zwischenzertifikate lediglich in Dateien vorbereitet. Für eine ausgereifte Lösung könnten Sie eine eigene TokenConsumer-Implementierung entwickeln, in der mittels der Online-CRL-Datenbank und des Online Certificate Status Protocol (OCSP) eine Zertifikat- und CRL-Verifizierung durchgeführt wird.

  • Das Benutzernamenstoken mit einem Kennwort schützen

    Es wird empfohlen, ein Kennwort nicht ohne Zugriffsschutz in einem Benutzernamenstoken an einen Downstream-Server zu senden. Sie können in einem solchen Fall das Kennwort entweder auf der Transportebene schützen, z. B. durch Verwendung von SSL (z. B. HTTPS), oder die XML-Verschlüsselung innerhalb von Web Services Security verwenden, um das Kennwort zu schützen. Welches die beste Sicherungsmethode ist, ist abhängig von Ihrer Umgebung. In einigen besonderen Umgebungen, in denen Sie sicher sind, dass das Kennwort keinen Angriffen ausgesetzt ist, ist es jedoch möglich, ein Kennwort unverschlüsselt an einen Downstream-Server zu senden.

Die Sicherung von Web-Services beinhaltet wesentlich mehr als nur die Verwendung einer digitalen XML-Signatur und der XML-Verschlüsselung. Um einen Web-Service richtig schützen zu können, müssen Sie mit der Public Key Infrastructure (PKI) vertraut sein. Der Grad an Sicherheit, den Sie benötigen, ist abhängig von der implementierten Umgebung und von Ihren Verwendungsmustern. Allerdings gibt es einige grundlegende Regeln und bewährte Verfahren zur Sicherung von Web-Services. Es wird empfohlen, Bücher zu PKI und Informationen zum BSP (Basic Security Profile) der Web Services Interoperability Organization (WS-I) zu lesen.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_secconsider6wssec
Dateiname:rwbs_secconsider6wssec.html