wake-up-neo.net

Sichere Webdienste: REST über HTTPS vs SOAP + WS-Sicherheit. Was ist besser?

Ich bin in keiner Weise ein Sicherheitsexperte, aber ich bevorzuge die Erstellung von Webdiensten im REST-Stil.

Bei der Erstellung eines neuen Dienstes, der die von ihm übertragenen Daten sicher haben muss. Wir haben uns überlegt, welcher Ansatz sicherer ist - REST mit HTTPS oder ein SOAP WS mit WS-Security.

Ich habe den Eindruck, wir könnten HTTPS für alle Webservice-Aufrufe verwenden, und dieser Ansatz wäre sicher. Meiner Ansicht nach ist "wenn HTTPS gut genug für Banken- und Finanzwebsites ist, ist es gut genug für mich". Auch hier bin ich kein Experte in diesem Bereich, aber ich denke, dass diese Leute über dieses Problem gründlich nachgedacht haben und mit HTTPS vertraut sind.

Ein Mitarbeiter ist anderer Meinung und sagt SOAP und WS-Security ist der einzige Weg.

Das Web scheint auf der ganzen Linie.

Vielleicht könnte die Community hier die Vor- und Nachteile eines jeden abwägen? Vielen Dank!

181
Vinnie

HTTPS sichert die Übertragung der Nachricht über das Netzwerk und gibt dem Client eine gewisse Sicherheit hinsichtlich der Identität des Servers. Dies ist wichtig für Ihre Bank oder Ihren Online-Börsenmakler. Ihr Interesse an der Authentifizierung des Clients liegt nicht in der Identität des Computers, sondern in Ihrer Identität. So werden Kartennummern, Benutzernamen, Passwörter usw. verwendet, um Sie zu authentifizieren. In der Regel werden dann einige Vorsichtsmaßnahmen getroffen, um sicherzustellen, dass die Einreichungen nicht manipuliert wurden. Im Großen und Ganzen wird jedoch davon ausgegangen, dass alles, was in der Sitzung passiert, von Ihnen initiiert wurde.

WS-Security bietet Vertraulichkeits- und Integritätsschutz von der Erstellung der Nachricht bis zum Verbrauch. Anstatt sicherzustellen, dass der Inhalt der Kommunikation nur vom richtigen Server gelesen werden kann, wird sichergestellt, dass er nur vom richtigen Prozess auf dem Server gelesen werden kann. Anstatt davon auszugehen, dass alle Kommunikationen in der sicher initiierten Sitzung vom authentifizierten Benutzer stammen, muss jeder einzelne signiert werden.

Hier gibt es eine amüsante Erklärung, an der nackte Motorradfahrer beteiligt sind:

http://blogs.msdn.com/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Daher bietet WS-Security mehr Schutz als HTTPS und SOAP bietet eine umfangreichere API als REST. Meiner Meinung nach sollten Sie den Overhead von SOAP und WS-Security überspringen, es sei denn, Sie benötigen die zusätzlichen Funktionen oder den Schutz wirklich. Ich weiß, es ist ein bisschen umstritten, aber die Entscheidungen darüber, wie viel Schutz tatsächlich gerechtfertigt ist (und nicht nur, was cool wäre), müssen von denen getroffen werden, die das Problem genau kennen.

132
Bell

Die REST-Sicherheit ist transportabhängig, die SOAP -Sicherheit jedoch nicht.

REST erbt Sicherheitsmaßnahmen vom zugrunde liegenden Transport, während SOAP seine eigenen über WS-Security definiert.

Wenn wir über REST sprechen, werden über HTTP alle angewendeten Sicherheitsmaßnahmen vererbt. Dies wird als Sicherheit auf Transportebene bezeichnet.

Die Sicherheit auf Transportebene sichert Ihre Nachricht nur, solange sie sich auf der Leitung befindet. Sobald sie die Leitung verlässt, ist die Nachricht nicht mehr gesichert.

Mit WS-Security wird jedoch die Sicherheit auf Nachrichtenebene gewährleistet - auch wenn die Nachricht den Transportkanal verlässt, bleibt sie dennoch geschützt. Außerdem können Sie mit der Sicherheit auf Nachrichtenebene die Nachricht teilweise verschlüsseln (nicht die gesamte Nachricht, sondern nur die gewünschten Teile). Mit der Sicherheit auf Transportebene ist dies jedoch nicht möglich.

In WS-Security gibt es Maßnahmen zur Authentifizierung, Integrität, Vertraulichkeit und Nicht-Zurückweisung, während SSL die Nicht-Zurückweisung nicht unterstützt [bei zweibeinigen OAuth.

In Bezug auf die Leistung ist SSL sehr viel schneller als WS-Security.

Vielen Dank...

65

Technisch ist die Art und Weise, wie Sie es formuliert haben, auch nicht korrekt, da die Kommunikation der SOAP -Methode nicht sicher ist und die REST -Methode nichts gesagt hat über die Authentifizierung legitimer Benutzer.

HTTPS verhindert, dass Angreifer die Kommunikation zwischen zwei Systemen abhören . Es wird auch überprüft, ob das Hostsystem (Server) tatsächlich das Hostsystem ist, auf das der Benutzer zugreifen möchte.

WS-Security verhindert, dass nicht autorisierte Anwendungen (Benutzer) auf das System zugreifen.

Wenn ein RESTful-System die Möglichkeit hat, Benutzer zu authentifizieren, und eine SOAP Anwendung mit WS-Security HTTPS verwendet, sind beide wirklich sicher. Es ist nur eine andere Art der Darstellung und des Zugriffs auf Daten.

22
kemiller2002

Siehe den wiki Artikel:

In Punkt-zu-Punkt-Situationen können Vertraulichkeit und Datenintegrität für Webdienste auch mithilfe von TLS (Transport Layer Security) erzwungen werden, indem beispielsweise Nachrichten über https gesendet werden.

WS-Security behebt jedoch das größere Problem der Aufrechterhaltung der Integrität und Vertraulichkeit von Nachrichten, bis eine Nachricht vom Ursprungsknoten gesendet wurde, und bietet so genannte End-to-End-Sicherheit.

Das ist:

  • HTTPS ist ein Transportschicht-Sicherheitsmechanismus (Punkt-zu-Punkt-Sicherheitsmechanismus)
  • WS-Security ist ein End-to-End-Sicherheitsmechanismus auf Anwendungsebene.
19
toolkit

Wie Sie sagen, REST ist gut genug für Banken, sollte also gut genug für Sie sein.

Die Sicherheit hat zwei Hauptaspekte: 1) Verschlüsselung und 2) Identität.

Die Übertragung in SSL/HTTPS ermöglicht die drahtlose Verschlüsselung. Sie müssen jedoch auch sicherstellen, dass beide Server bestätigen können, dass sie wissen, mit wem sie sprechen. Dies kann über SSL-Client-Zertifikate erfolgen, Geheimnisse freigeben usw.

Ich bin sicher, man könnte den Fall, dass SOAP ist "sicherer", aber wahrscheinlich in keiner nennenswerten Weise. Die nackte Motorradfahrer-Analogie ist niedlich, aber wenn genau, würde dies bedeuten, dass das gesamte Internet unsicher ist .

15
pbreitenbach

Ich habe noch nicht den Repräsentanten, der benötigt wird, um einen Kommentar hinzuzufügen, oder ich hätte dies gerade zu Bells Antwort hinzugefügt. Ich denke, Bell hat sehr gute Arbeit geleistet, um die Vor- und Nachteile der beiden Ansätze auf höchster Ebene zusammenzufassen. Nur ein paar andere Faktoren, die Sie berücksichtigen sollten:

1) Müssen die Anforderungen zwischen Ihren Kunden und Ihrem Service über Vermittler abgewickelt werden, die Zugriff auf die Nutzlast benötigen? In diesem Fall ist WS-Security möglicherweise besser geeignet.

2) Es ist tatsächlich möglich, SSL zu verwenden, um dem Server mithilfe einer Funktion, die als gegenseitige Authentifizierung bezeichnet wird, Sicherheit hinsichtlich der Clientidentität zu geben. Außerhalb einiger sehr spezieller Szenarien wird dies jedoch aufgrund der Komplexität der Konfiguration kaum genutzt. Bell hat also Recht, dass WS-Sec hier viel besser passt.

3) Die Einrichtung und Wartung von SSL (auch in der einfacheren Konfiguration) kann im Allgemeinen aufgrund von Problemen mit der Zertifikatsverwaltung problematisch sein. Jemanden zu haben, der weiß, wie man das für Ihre Plattform macht, ist ein großes Plus.

4) Wenn Sie möglicherweise eine Form der Zuordnung von Anmeldeinformationen oder des Identitätsverbundes ausführen müssen, ist WS-Sec möglicherweise den Aufwand wert. Nicht, dass Sie dies mit REST nicht tun können, Sie haben nur weniger Struktur, um Ihnen zu helfen.

5) Es kann schmerzhafter sein, WS-Security an die richtigen Stellen auf der Clientseite zu bringen, als man denkt.

Letztendlich hängt es jedoch von vielen Dingen ab, die wir wahrscheinlich nicht wissen werden. Für die meisten Situationen würde ich sagen, dass beide Ansätze "sicher genug" sind und daher nicht der Hauptentscheidungsfaktor sein sollten.

13
sfitts
Brace yourself, here there's another coming :-)

Heute musste ich meiner Freundin den Unterschied zwischen der Ausdruckskraft von WS-Security und HTTPS erklären. Sie ist Informatikerin und versteht (vielleicht besser als ich), was Verschlüsselung oder Signatur bedeutet, auch wenn sie nicht das ganze XML-Mumbo-Jumbo kennt. Ich wollte jedoch ein starkes Image, mit dem sie wirklich verstehen kann, wofür Dinge nützlich sind, anstatt wie sie implementiert werden (das kam etwas später, sie ist nicht davongekommen :-)).

Also geht es so. Angenommen, Sie sind nackt und müssen mit Ihrem Motorrad zu einem bestimmten Ziel fahren. Im Fall (A) gehen Sie durch einen transparenten Tunnel: Ihre einzige Hoffnung, nicht wegen obszönen Verhaltens verhaftet zu werden, ist, dass niemand hinschaut. Das ist nicht gerade die sicherste Strategie, die Sie entwickeln können ... (Beachten Sie den Schweißtropfen auf der Stirn des Mannes :-)). Das ist äquivalent zu a POST in clear, und wenn ich "äquivalent" sage, meine ich das. Im Fall (B) sind Sie in einer besseren Situation. Der Tunnel ist undurchsichtig, so wie Solange Sie in den Tunnel hineinfahren, ist Ihre öffentliche Aufzeichnung sicher, dies ist jedoch immer noch nicht die beste Situation. Sie müssen immer noch das Haus verlassen und den Tunneleingang erreichen, und sobald Sie den Tunnel verlassen, müssen Sie wahrscheinlich aussteigen und irgendwohin gehen ... und das gilt auch für HTTPS. Richtig, Ihre Nachricht ist sicher, während sie die größte Kluft überquert: Wenn Sie sie jedoch auf der anderen Seite übermittelt haben, wissen Sie nicht wirklich, wie viele Phasen sie durchlaufen müssen, bevor Sie die reale erreichen Punkt, an dem die Daten verarbeitet werden. Und natürlich können all diese Phasen etwas anderes als HTTP verwenden: eine klassische MSMQ, die Anforderungen puffert, die nicht sofort zugestellt werden können. Was passiert, wenn jemand Ihre Daten versteckt, während sie sich in der Datenbank befinden Hm. (Lesen Sie dieses "hm" so, wie es Morpheus am Ende des Satzes aussprach Hink, ist es Luft, die du atmest? "). Die vollständige Lösung (c) in dieser Metapher ist schmerzlich trivial: zieh dir ein paar verdammte Klamotten an und vor allem den Helm, während du auf dem Motorrad bist !!! So können Sie sicher herumlaufen, ohne sich auf die Undurchsichtigkeit der Umgebung verlassen zu müssen. Die Metapher ist hoffentlich klar: Die Kleidung kommt mit Ihnen, unabhängig von der Durchschnittlichkeit oder der umgebenden Infrastruktur, wie dies bei der Nachrichtensicherheit der Fall ist. Darüber hinaus können Sie beschließen, einen Teil abzudecken, aber einen anderen preiszugeben (und das können Sie auf persönlicher Basis tun: Die Flughafensicherheit kann Jacke und Schuhe ausziehen, während Ihr Arzt möglicherweise über eine höhere Zugriffsstufe verfügt). Denken Sie jedoch daran, dass es sich bei Hemden mit kurzen Ärmeln um Hemden handelt schlechtes Training, auch wenn Sie stolz auf Ihren Bizeps sind :-) (besser ein Polo oder ein T-Shirt).

Ich bin froh zu sagen, dass sie es verstanden hat! Ich muss sagen, dass die Metapher der Kleidung sehr mächtig ist: Ich war versucht, sie für die Einführung des Konzepts der Politik zu verwenden (Disco-Clubs lassen Sie nicht in Sportschuhen zu; Sie können nicht gehen, um Geld in einer Bank in Ihrer Unterwäsche abzuheben , das ist zwar durchaus akzeptabel, schau doch mal beim balancieren auf einer Brandung zu ;-)

Architektur - WS, wilde Ideen

Mit freundlicher Genehmigung: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-) motorrad-nackt.aspx

11
taus-iDeveloper

Ich arbeite jeden Tag in diesem Bereich, daher möchte ich die guten Kommentare dazu zusammenfassen, um dies abzuschließen:

SSL (HTTP/s) ist nur eine Ebene, die Folgendes gewährleistet:

  1. Der Server, mit dem eine Verbindung hergestellt wird, präsentiert ein Zertifikat, das seine Identität bestätigt (obwohl dies durch DNS-Vergiftung gefälscht werden kann).
  2. Die Kommunikationsschicht ist verschlüsselt (kein Abhören).

WS-Security und verwandte Standards/Implementierungen verwenden PKI, die:

  1. Beweisen Sie die Identität des Kunden.
  2. Beweisen Sie, dass die Nachricht während der Übertragung (MITM) nicht geändert wurde.
  3. Ermöglicht dem Server die Authentifizierung/Autorisierung des Clients.

Der letzte Punkt ist wichtig für Serviceanfragen, wenn die Identität des Kunden (Anrufers) von größter Bedeutung ist, um zu wissen, ob er berechtigt sein sollte, solche Daten vom Service zu empfangen. Standard-SSL ist eine Einweg- (Server-) Authentifizierung und dient nicht zur Identifizierung des Clients.

9
Darrell Teague

REST über HTTPS Sollte eine sichere Methode sein, solange der API-Anbieter die Autorisierung auf einem Serverende implementiert. Auch bei Webanwendungen greifen wir auf eine Webanwendung über HTTPS und einige Authentifizierungen/Autorisierungen zu. Herkömmlicherweise hatten Webanwendungen keine Sicherheitsprobleme. Dann würde Restful API auch Sicherheitsprobleme problemlos beheben!

5
Rakesh Waghela

Die Antwort hängt tatsächlich von Ihren spezifischen Anforderungen ab.

Müssen Sie zum Beispiel Ihre Webnachrichten schützen, oder ist keine Vertraulichkeit erforderlich, und Sie müssen nur die Endparteien authentifizieren und die Nachrichtenintegrität sicherstellen? Wenn dies der Fall ist - und dies ist häufig bei Webdiensten der Fall -, ist HTTPS wahrscheinlich der falsche Hammer.

Lassen Sie jedoch aus meiner Erfahrung die Komplexität des von Ihnen erstellten Systems nicht außer Acht. Es ist nicht nur einfacher, HTTPS korrekt bereitzustellen, sondern eine Anwendung, die sich auf die Transportschichtsicherheit stützt, ist auch einfacher zu debuggen (über einfaches HTTP).

Viel Glück.

5
user105991

Wenn Ihr RESTFul-Aufruf in den HTML-Text der HTTP-Anforderung eingebettete XML-Nachrichten hin und her sendet, sollten Sie in der Lage sein, alle Vorteile von WS-Security wie XML-Verschlüsselung, Zertifikate usw. in Ihren XML-Nachrichten zu nutzen, während Sie die Sicherheitsfunktionen verwenden sind über http verfügbar, z. B. SSL/TLS-Verschlüsselung.

4
LRJ