WEBSERVICE: Prüfung von Schnittstellen (APIs)

Wie bei klassischen Webapplikationen (siehe Modul WEBAPP) besteht auch bei Webservices ein hohes Risiko, dass auf nicht autorisierte Weise auf Daten zugegriffen werden kann, was einen Verlust der Vertraulichkeit bedeutet. Überdies besteht die Gefahr, dass Daten auf nicht autorisierte Weise manipuliert werden können, wodurch deren Integrität verletzt wird. Darüber hinaus stellt die Störung der Verfügbarkeit von Webservices (Denial-of-Service) oftmals ebenfalls ein hohes Risiko dar, da kritische Geschäftsprozesse ohne entsprechende Webservicefunktionalität nicht mehr ordnungsgemäß funktionieren.
Webservices greifen auf verschiedene Webtechnologien und -protokolle zurück, die größtenteils auch bei klassischen Webapplikationen zum Einsatz kommen. In der Regel werden hierbei spezielle Formate oder eine spezielle Syntax innerhalb gewöhnlicher HTTP-Anfragen verwendet (z. B. in Form einer REST API oder des XML-basierten SOAP). Neben typischen Schwachstellen in Back-End-Anwendungen, wie beispielsweise Buffer Overfow, SQL Injection-Schwachstellen oder (De)Serialization, existieren ferner Webservice-spezifsche Sicherheitsschwächen, wie etwa XML/XPath Injection oder XML Signature Wrapping, die für Webservices ein Sicherheitsrisiko darstellen können.

Im Rahmen des Sicherheitstests wird der ausgewählte Webservice aus unterschiedlichen Perspektiven auf Schwachstellen geprüft. Je nach Testschwerpunkt und Funktionalität des Webservice, beispielsweise im Kontext von Business-to-Consumer (B2C)- oder Business-to-Business (B2B)-Geschäftsprozessen, kann der Fokus auf unterschiedliche Schutzziele (z. B. Vertraulichkeit, Verfügbarkeit, Integrität) gelegt werden. Des Weiteren wird auch bei jeder Sicherheitsanalyse einer Mobile App der dazugehörige Webservice getestet. Lastbasierte Denial-of-Service-Angrife führt die SySS nicht durch, jedoch wird geprüft, wo es zu DoS durch Fehlkonfiguration des Servers bzw. durch eine fehlerhafte Implementierung des Webservice kommen kann.
Auch etwaige zum Einsatz kommende Authentisierungsprotokolle wie OpenID Connect (OIDC) oder OAuth und Single Sign-on-Dienste wie Active Directory Federation Services (ADFS) sowie deren konkrete Implementierung werden geprüft.

Die Durchführung eines Sicherheitstests von Webservices richtet sich primär nach den eingesetzten Technologien und Architekturen (z. B. SOAP, RESTful, JSON-basiert usw.) sowie nach der bereitgestellten Funktionalität, die in der Webservicespezifikation dokumentiert ist.
Der Testablauf entspricht in der Regel dem folgenden Muster:

• Analyse der Webservicespezifikation
• Bedrohungsanalyse zur Identifikation möglicher Angriffe, beispielsweise zum unautorisierten Zugriff auf fremde Daten oder der unautorisierten Manipulation fremder Daten
• Überprüfung von Schwachstellen in Back-End-Systemen (z. B. Buffer Overfow, SQL Injection, XML Injection,  (De)Serialization)
• Überprüfung von weiteren, bei Webservices auftretenden Schwachstellen (z. B. XML/XPath Injection, XML Signature Wrapping)
• Überprüfung der Zugriffskontrolle/Sitzungsverwaltung (sofern vorhanden)
• Suche nach Fehlern in der Anwendungslogik bereitgestellter Funktionen

Für die Durchführung der Sicherheitsanalyse werden sowohl spezielle Softwaretools wie SoapUI, Burp Suite Professional oder Postman als auch manuelle Prüfmethoden eingesetzt.

Für den Sicherheitstest eines Webservice müssen dessen URL sowie dessen Spezifikation bzw. Schnittstellenbeschreibung, beispielsweise als WSDL- oder OpenAPI-Datei, bereitgestellt werden. Darüber hinaus sollten jeweils Beispiele für Anfragen bereitgestellt und die mögliche Authentifizierung beschrieben werden. Dies ist dann wichtig, wenn die Authentifizierung von einem Identity Provider vorgenommen wird, der jedoch nicht Teil des Tests ist. Die Erfahrung hat gezeigt, dass die Schnittstellenbeschreibung oft nicht ausreicht, um eine fehlerfreie Kommunikation mit dem Service herzustellen.

Die Sicherheitsanalyse von Webservices entspricht im Wesentlichen der von Webapplikationen, weshalb dieselben organisatorischen und technischen Aspekte zu berücksichtigen sind (siehe Modul W E B A P P).

Ansprechperson: Die Klärung von Zuständigkeiten sowie die Feststellung verantwortlicher Personen sollte rechtzeitig vor einem geplanten Sicherheitstest geschehen. Ferner sollten alle Projektbeteiligten vorab über den Termin und das Ziel des Tests informiert werden. Während des Projektzeitraums sollte zudem eine Ansprechperson für Rückfragen bezüglich des zu testenden Webservice zur Verfügung stehen.

Abhängigkeiten: Organisatorische und technische Abhängigkeiten des Webservice sollten der SySS mitgeteilt werden, wozu zum Beispiel die Weiterleitung von Daten an weitere Dienste zählt. Dies kann im Rahmen des Kick-off-Gesprächs geschehen. Werden der Webservice oder die nachgelagerten Dienste von Dritten bereitgestellt, benötigt die SySS vor Testbeginn eine schriftliche Testgenehmigung.

Anmeldeinformationen: Sollte für die Nutzung des zu testenden Webservice eine Zugriffskontrolle implementiert sein, benötigt die SySS mindestens zwei Benutzerkonten pro Berechtigungsstufe, aus deren Perspektive der Sicherheitstest durchgeführt werden soll. Stehen keine entsprechenden Anmeldedaten zur Verfügung, kann ein Test nur aus der Perspektive eines externen Angreifers ohne gültige Anmeldedaten erfolgen. Aus einer solch eingeschränkten Testperspektive heraus können Sicherheitsschwächen in einem authentifizierten Kontext eines Webservice in der Regel nicht gefunden werden. Des Weiteren sollte auch beschrieben werden, wie die Authentifizierung durchgeführt wird. Wenn die Authentifizierung beispielsweise von einem Identity Provider vorgenommen wird, der nicht Teil des Tests ist, taucht dieser unter Umständen nicht in der Dokumentation des Webservice auf.

Testdaten/Testsystem: Wie auch bei Sicherheitstests von Webapplikationen gilt bei der Analyse von Webservices, dass sowohl produktive Systeme mit entsprechenden Nutzdaten als auch reine Testsysteme mit Testdaten im Rahmen der Sicherheitsanalyse untersucht werden können. Testdatensätze, auf welche die für den Sicherheitstest bereitgestellten Benutzerkonten zugreifen können, sollten bereits vor Testbeginn eingerichtet werden.

Darüber hinaus ist bei der Arbeit mit reinen Testsystemen zu beachten, dass Ergebnisse des Sicherheitstests nur dann aussagekräftig sind und auf das produktive System übertragen werden können, wenn ihre Funktionalität und Architektur zu großen Teilen identisch sind.