Sichere Webdienste: REST über HTTPS vs SOAP + WS-Sicherheit. Welches ist besser? [geschlossen]

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

Bei der Erstellung eines neuen Dienstes, für den die übertragenen Daten sicher sein müssen. Wir haben eine Debatte darüber geführt, welcher Ansatz sicherer ist - REST mit HTTPS oder SOAP WS mit WS-Security.

Ich habe den Eindruck, wir könnten HTTPS für alle Webdienstaufrufe verwenden, und dieser Ansatz wäre sicher. Ich sehe das so: "Wenn HTTPS für Bank- und Finanzwebsites gut genug ist, ist es für mich gut genug." Auch hier bin ich kein Experte auf diesem Gebiet, aber ich würde denken, dass diese Leute über dieses Problem sehr gründlich nachgedacht haben und mit HTTPS vertraut sind.

Ein Mitarbeiter ist anderer Meinung und sagt, SOAP und WS-Sicherheit seien 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!

HTTPS sichert die Übertragung der Nachricht über das Netzwerk und bietet 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. Daher 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 alles, was in der Sitzung passiert, als von Ihnen initiiert angesehen.

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 signiert werden.

Hier gibt es eine amüsante Erklärung für nackte Motorradfahrer:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

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

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

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

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

Die Sicherheit auf Transportebene sichert Ihre Nachricht nur, während sie sich auf dem Kabel befindet. Sobald sie das Kabel verlässt, ist die Nachricht nicht mehr gesichert.

Mit WS-Security ist die Sicherheit auf Nachrichtenebene jedoch geschützt - obwohl die Nachricht den Transportkanal verlässt, bleibt sie dennoch geschützt. Mit der Sicherheit auf Nachrichtenebene können Sie die Nachricht teilweise verschlüsseln [nicht die gesamte Nachricht, sondern nur die gewünschten Teile] - aber mit der Sicherheit auf Transportebene können Sie dies nicht tun.

WS-Security verfügt über Maßnahmen zur Authentifizierung, Integrität, Vertraulichkeit und Nicht-Zurückweisung, während SSL die Nicht-Zurückweisung nicht unterstützt [mit zweibeinigem OAuth].

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

Vielen Dank...

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

HTTPS verhindert, dass Angreifer abhören zwischen zwei Systemen auf die Kommunikation. Außerdem wird ü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 Benutzer authentifizieren kann und eine SOAP-Anwendung mit WS-Security HTTPS verwendet, sind beide wirklich sicher. Es ist nur eine andere Art, Daten zu präsentieren und darauf zuzugreifen.

Siehe den Wiki- Artikel:

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

WS-Security behebt jedoch das umfassendere 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)
• WS-Security ist ein Sicherheitsmechanismus auf Anwendungsebene (Ende-zu-Ende).

Wie Sie sagen, ist REST 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 Verschlüsselung über das Kabel. 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, Freigabegeheimnisse usw. erfolgen.

Ich bin sicher, man könnte behaupten, SOAP sei "sicherer", aber wahrscheinlich nicht in nennenswerter Weise. Die nackte Motorradfahrer-Analogie ist niedlich, aber wenn sie genau ist, würde dies bedeuten, dass das gesamte Internet unsicher ist.

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

1) Müssen die Anfragen zwischen Ihren Kunden und Ihrem Service über Vermittler erfolgen, die Zugriff auf die Nutzdaten benötigen? Wenn ja, ist WS-Security möglicherweise besser geeignet.

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

3) SSL kann im Allgemeinen aufgrund der Probleme bei der Zertifikatsverwaltung ein wenig schwierig zu einrichten und zu warten sein (auch in der einfacheren Konfiguration). 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 einen Identitätsverbund durchfü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, die gesamte WS-Sicherheit auf der Client-Seite an die richtigen Stellen zu bringen, als Sie denken sollten.

Am Ende hängt es jedoch wirklich von vielen Dingen ab, die wir wahrscheinlich nicht wissen werden. Für die meisten Situationen würde ich sagen, dass jeder Ansatz "sicher genug" ist und dass dies nicht der entscheidende Faktor sein sollte.

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 selbst wenn sie nicht alle XML-Hokuspokus kennt, versteht sie (vielleicht besser als ich), was Verschlüsselung oder Signatur bedeutet. Ich wollte jedoch ein starkes Image, das sie wirklich verstehen lässt, wofür Dinge nützlich sind, anstatt wie sie implementiert werden (das kam etwas später, sie konnte sich dem nicht entziehen :-)).

So geht es also. Angenommen, Sie sind nackt und müssen Ihr 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, besteht darin, dass niemand hinschaut. Das ist nicht gerade die sicherste Strategie, mit der Sie herauskommen können ... (Beachten Sie den Schweißtropfen von der Stirn des Mannes :-)). Das entspricht eindeutig einem POST, und wenn ich "äquivalent" sage, meine ich das auch. Im Fall (B) befinden Sie sich in einer besseren Situation. Der Tunnel ist undurchsichtig, so lange Sie 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 wenn Sie einmal außerhalb des Tunnels sind, müssen Sie wahrscheinlich aussteigen und irgendwohin gehen ... und das gilt für HTTPS. Wahr, 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 genau, wie viele Phasen sie durchlaufen muss, bevor Sie den tatsächlichen Punkt erreichen, an dem die Daten verarbeitet werden. Und natürlich könnten alle diese Phasen etwas anderes als HTTP verwenden: ein klassisches MSMQ, das Anforderungen puffert, die beispielsweise nicht sofort bearbeitet werden können. Was passiert, wenn jemand Ihre Daten lauert, während er sich in dieser Vorverarbeitungssituation befindet? Hm. (Lesen Sie dieses "hm" als das von Morpheus am Ende des Satzes ausgesprochene "Glaubst du, es ist Luft, die du atmest?"). Die vollständige Lösung (c) in dieser Metapher ist schmerzlich trivial: Zieh dir verdammte Klamotten an, und besonders 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 wird unabhängig vom Mittelwert oder der umgebenden Infrastruktur mit Ihnen geliefert, so wie es die Sicherheit auf Message-Ebene tut. Darüber hinaus können Sie sich dafür entscheiden, einen Teil abzudecken, aber einen anderen zu enthüllen (und das auf persönlicher Basis: Die Flughafensicherheit kann Ihre Jacke und Schuhe ausziehen, während Ihr Arzt möglicherweise eine höhere Zugangsstufe hat), aber denken Sie daran, dass es Kurzarmhemden sind schlechte Übung, auch wenn Sie stolz auf Ihren Bizeps sind :-) (besser ein Polo oder ein T-Shirt).

Ich bin froh zu sagen, dass sie den Punkt verstanden hat! Ich muss sagen, dass die Kleidermetapher sehr mächtig ist: Ich war versucht, sie zur Einführung des Konzepts der Politik zu verwenden (Disco-Clubs lassen Sie nicht in Sportschuhen zu; Sie können in Ihrer Unterwäsche kein Geld bei einer Bank abheben , während dies ein vollkommen akzeptabler Look ist, während du dich auf einer Brandung balancierst; und so weiter), aber ich dachte, dass es für einen Nachmittag genug war ;-)

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-motorcycle-naked. aspx

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

SSL (HTTP / s) ist nur eine Schicht, die Folgendes sicherstellt:

1. Der Server, mit dem eine Verbindung hergestellt wird, legt ein Zertifikat vor, 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 des Transports (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 Clients (Anrufers) von größter Bedeutung ist, um zu wissen, ob er berechtigt sein sollte, solche Daten vom Service zu empfangen. Standard-SSL ist eine Einwegauthentifizierung (Serverauthentifizierung) und dient nicht zur Identifizierung des Clients.

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

Müssen Sie beispielsweise Ihre Webnachrichten schützen, oder ist keine Vertraulichkeit erforderlich, und Sie müssen lediglich 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.

Übersehen Sie jedoch meiner Erfahrung nach nicht die Komplexität des Systems, das Sie erstellen. Nicht nur HTTPS ist einfacher korrekt bereitzustellen, sondern eine Anwendung, die auf der Sicherheit der Transportschicht beruht, ist einfacher zu debuggen (über einfaches HTTP).

Viel Glück.

REST über HTTPS Sollte eine sichere Methode sein, solange der API-Anbieter die Autorisierung eines Serverendes implementiert. Auch bei Webanwendungen, bei denen wir über HTTPS und eine gewisse Authentifizierung / Autorisierung auf eine Webanwendung zugreifen, hatten Webanwendungen traditionell keine Sicherheitsprobleme, und die Restful API würde auch Sicherheitsproblemen problemlos entgegenwirken!

Wenn Ihr RESTFul-Aufruf XML-Nachrichten, die im HTML-Text der HTTP-Anforderung eingebettet sind, 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 alle Sicherheitsfunktionen verwenden sind über http verfügbar, z. B. SSL / TLS-Verschlüsselung.