Dieser Blogartikel befasst sich mit dem Grundprinzip von Webservices und wie diese vor Angriffen geschützt werden können. Dabei gehen wir auf allgemein anwendbare Sicherheitsmaßnahmen, aber auch Webservice-spezifische Methoden ein. Wir behandelt jedoch keine Framework-spezifischen Sicherheitsmaßnahmen. Hierzu sollten die jeweiligen Leitfäden befolgt werden.
Grundsätzlich werden Webservices verwendet, um die Kommunikation zwischen Maschinen zu ermöglichen bzw. zu erleichtern. Dabei gibt es kein eindeutiges Protokoll oder eine eindeutige Methode, das bzw. die universell als der Webservice angesehen wird/werden. Mit modernen Web-Applikationen verschwimmt der Begriff immer mehr und wird gelegentlich mit Web-Applikationen gleichgesetzt.
Meistens wird für Webservices entweder das REST (Representational State Transfer)-Konzept oder SOAP (Simple Object Access Protocol) eingesetzt und für den jeweiligen Verwendungszweck angepasst.
Webservices werden beispielsweise häufig für Application Programming Interface (API) oder Programmierschnittstellen verwendet. Anbieter wie Reddit, Twitter usw. erlauben hier über selbst entwickelte Skripte oder Anwendungen mit der Web-Applikation zu interagieren. Really Simple Syndication (RSS), also das weitverbreitete Format für Informations-Feeds, ist ebenso ein Webservice.
Im Alltag verwenden Web-Applikationen regelmäßig Webservices im Hintergrund, ohne dass der Benutzer dies merkt oder gar Zugriff auf diese Dienste erhält, klassisch für eine Microservice Architektur.
Unabhängig von der eingesetzten Technologie oder der dahinterliegenden Anwendung gibt es einige Grundsätze, die auch für Webservices gelten.
Transportverschlüsselung: Vernünftige Transportverschlüsselung über TLS, wie in diesem Artikel beschrieben, ist essentiell.
Eingabe Validierung und Ausgabe Codierung: Ebenso allgemein gültig ist, dass jeglichen benutzerdefinierten Daten misstraut werden muss und diese erst validiert werden müssen. Gleichermaßen müssen Ausgaben, die von einem Webservice stammen, codiert werden, um Cross-Site-Scripting (XSS) zu verhindern. Ganz wichtig in Bezug auf Validierung ist bei Webservices auch, dass alle Inhalte auf den korrekten Datentyp geprüft werden. Hier muss auch der entsprechende HTTP-Header betrachtet werden.
Antwort-Header: Sollte ein Webservice in Kontakt mit Clientbrowsern stehen, müssen alle Sicherheitsrelevanten Antwort-Header gesetzt sein wie bei klassischen Web-Applikationen. Mehr zu dem Thema finden Sie in diesem Artikel.
HTTP-Methoden-Whitelisting: Das Prinzip von „Weniger ist Mehr“ lässt aus Sicherheitssicht bei Webservices beispielsweise durch das Whitelisting von HTTP-Methoden widerspiegeln. Es sollten also explizit nur HTTP-Methoden erlaubt werden, die auch für den Service verwendet werden. Damit wird die Angriffsfläche reduziert.
Cross-Origin Resource Sharing (CORS): Besonders bei Webservices ist es wichtig, CORS sicher zu konfigurieren. Immer wieder finden wir bei unseren Penetration Tests uneingeschränktes CORS, da die Web-Applikation beispielsweise eine REST API über AJAX verwendet. Dadurch entsteht ein großes Angriffspotential. Das Thema CORS wurde in diesem Artikel bereits behandelt.
HTTP Status Codes: Speziell für Webservices wird immer wieder empfohlen, HTTP Status Codes korrekt zu verwenden; also HTTP 200 für erfolgreiche Zugriffe, HTTP 400 für fehlerhafte Anfragen, HTTP 401 bei fehlender Authentifizierung und so weiter. Dies bedeutet jedoch auf keinen Fall, dass detaillierte Fehlermeldungen verwendet werden sollten. Diese würden einem Angreifer weitere, wichtige Informationen liefern.
Die Verwendung der entsprechenden HTTP Status Codes ist demnach durchaus zu empfehlen, jedoch sollte die entsprechende Information möglichst generisch gehalten werden. Beispielsweise sollte es einem Benutzer ohne entsprechende Rechte nicht möglich sein zu identifizieren, ob eine Ressource existiert oder nicht.
Autorisierung und Authentifizierung: Auch für Webservices ein heikles Thema, das auf verschiedene Weisen behandelt werden kann. Verschiedene Methoden, wie dies bei Webservices umgesetzt werden kann, finden Sie in diesem Artikel. Egal ob OAuth, JWT, Mututal SSL/TLS oder eine sichere Alternative eingesetzt wird; wichtig dabei ist, dass die gewählte Methode vollständig für alle Funktionen verwendet wird.
Vertrauliche Daten in URL: Auch wie bei Web-Applikationen dürfen vertrauliche Informationen nicht in der URL auftauchen, wie etwa über HTTP GET (https://secur.ai/beispiel/api?secret=gib134237son). Diese können über Kopieren/Einfügen, Logdateien, Browser-Favoriten oder -Chronik, Shoulder Surfing oder andere Wege entwendet werden.
Rate-Limiting: Ein häufig angesprochenes Thema, auch in Bezug auf Webservices, ist das sogenannte Rate-Limiting, also das Limitieren der Aufrufe. Dadurch werden Bruteforce-Angriffe, das Enumerieren von Informationen oder andere Angriffe deutlich erschwert. Wie dies implementiert wird, ist von dem Projekt abhängig, beispielsweise über NGINX oder In-Memory Datenbanken wie REDIS.
Bei der Verwendung des SOAP-Protokolls wird die Erweiterung WS-Security (oder WSS) empfohlen, die Integrität und Vertraulichkeit für SOAP ermöglicht.
Für den effektiven Datenaustausch wird JSON vor XML-basierenden Formaten empfohlen. Wenn dennoch ein XML-basierendes Format verwendet wird, muss dies sicher verarbeitet werden, um die hier behandelte XXE Schwachstelle zu verhindern.
Zusammenfassung
In Summe unterscheiden sich Sicherheitsmaßnahmen von Web-Applikationen und Webservices kaum. Dieselben Prinzipien lassen sich fast universell anwenden.
Transportverschlüsselung über TLS ist unumgänglich. Jegliche benutzerkontrollierten Daten müssen validiert werden und Ausgaben müssen codiert werden. Sobald ein Webservice in Kontakt mit Clientbrowsern kommt, sind sicherheitsrelevante HTTP-Header empfohlen. Es sollten nur die HTTP-Methoden erlaubt sein, die auch verwendet werden. Die Antwortcodes sollten gezielt verwendet werden, ohne unerlaubte Einsicht in die Applikation zu erlangen.
Autorisierung und Authentifizierung muss mit Hilfe von etablierten Systemen wie JWT, OAuth oder Mutual SSL/TLS, abhängig von der Applikation, wohl durchdacht und durchgehend implementiert werden. Eine Form von Rate-Limiting ist empfohlen und für das verwendete Datenformat sollte nach Möglichkeit eher JSON als XML verwendet werden.
