© MicroOn/Shutterstock.com
Unbekanntere Schwachstellenarten in Webanwendungen und APIs

Beyond OWASP Top 10


Auch wenn beim Entwickeln von Anwendungen grundlegende Sicherheitslücken wie Cross-Site Scripting (XSS) oder SQL Injections vermieden werden, sind Webapplikationen und Schnittstellen anfällig für Schwachstellen. Dieser Artikel stellt ausgewählte, unbekanntere Schwachstellenarten vor, die ein Penetration-Tester in der Berufspraxis findet; zudem gibt er zur Vertiefung des Themas Hinweise auf gute Fachquellen.

Sicherheit im Web muss beim Entwerfen und Entwickeln von Webanwendungen und Schnittstellen von Anfang an berücksichtigt werden. Dieses Bewusstsein und das notwendige Wissen werden jedoch in Studium und Kursen unzureichend vermittelt, wovon zahlreiche Schwachstellen in verbreiteten Anwendungen zeugen.

Im Dienst der Websicherheit – Open Web Application Security Project

Das Open Web Application Security Project (OWASP) [1] ist eine Non-Profit-Organisation, die sich auf die Fahne geschrieben hat, die Sicherheit von Webanwendungen zu verbessern. Dazu veröffentlichen die zahlreichen freiwilligen Projektmitglieder unter anderem technische Dokumentationen, Softwarebibliotheken und Testwerkzeuge. Diese sind allesamt kostenfrei nutzbar unter freien Lizenzen wie Creative Commons und zudem als Dokument und als Software in bearbeitbaren Formaten beziehungsweise im Quelltext verfügbar. Ihre wohl bekannteste Publikation ist die OWASP Top 10, eine Liste der zehn kritischsten Schwachstellen in Webanwendungen. In der Publikation werden die Ursachen für die Schwachstellen und die Gegenmaßnahmen ausführlich erläutert [2]. Die Liste wurde erstmals 2003 veröffentlicht, zuletzt 2017 angepasst und ist vielen Entwicklern ein Begriff. Ihre nächste Aktualisierung steht im Herbst 2020 an [3].

Manche Anbieter gehen sogar so weit, ihre Software als sicher zu bezeichnen, weil sie gemäß der OWASP Top 10 entwickelt worden sei. Nicht immer seriöse Sicherheitsdienstleister bieten Tests nur gegen die OWASP-Top-10-Sicherheitslücken an und stellen danach der Anwendung ein Sicherheitszertifikat aus. Das ist jedoch unseriös, denn die Liste ist nach eigener Zielsetzung kein Sicherheitsstandard [4]. Die Verantwortlichen des Open Web Application Security Projects sehen die OWASP Top 10 als Awareness-Dokument, das einem breiten Publikum von Informationssicherheitsverantwortlichen über Entwickler bis zu Testern grundlegende Schwachstellen verständlich machen soll. Die Ursachen der Schwachstellen sollten auf jeden Fall bei der Entwicklung von Webanwendungen berücksichtigt werden. Die Top 10 können dabei natürlich nicht alle Schwachstellenarten abdecken, die bei modernen Webanwendungen und Schnittstellen bei einem technischen Sicherheitsaudit wie einem Web Application Penetration Test aufgespürt werden.

Gute Vorbereitung ist die halbe Miete – Interception Proxy

Die Untersuchung einer Webanwendung oder Schnittstelle beginnt sowohl für wohlmeinende Tester als auch für böswillige Angreifer in der Regel damit, einen Interception Proxy einzurichten. Der Proxy fungiert als Man in the Middle zwischen dem Browser und der Anwendung, die angegriffen wird. Er zeichnet den gesamten HTTP(S)-Verkehr auf und erlaubt es, Anfragen beliebig zu wiederholen oder zu manipulieren. Der bekannteste Vertreter ist der Burp Proxy [5] (Abb. 1).

ully_beyond_1.tif_fmt1.jpgAbb. 1: Burp-Proxy mit Anfrage (Request) links und Antwort (Response) rechts

Gefälschte Anfragen – Server-Side Request Forgery (SSRF)

Was hat es mit SSRF [6] auf sich? Ursache dieser Schwachstelle ist, dass eine Anwendung einen Request ausführt, der als Folge eine interne oder externe Ressource aufruft und dessen Ziel der Benutzer ganz oder teilweise vorgeben kann. Das ist heutzutage nichts Ungewöhnliches – viele Anwendungen oder Schnittstellen nehmen in der Anfrage direkt einen URL entgegen und tun etwas damit, überprüfen beispielsweise den angegebenen Link oder erzeugen aus einem Bildpfad ein Vorschaubild. In anderen Fällen leiten sie Teile einer Anfrage an andere Systeme weiter, etwa zur Authentifizierung oder zum Monitoring – oder an ein Zahlungs-Gateway oder ein anderes externes API im Hintergrund.

Oft bestehen dabei Vertrauensbeziehungen, weil Server sich selbst und anderen Systemen im selben Netzwerk vertrauen. Nutzen Angreifer das aus, können sie somit Firewalls umgehen und aus dem Internet Dienste erreichen, die eigentlich nur auf dem lokalen Host oder im internen Netz verfügbar sind. Sie können dann das entfernte Netzwerk scannen und sensible interne Daten auslesen. Gegebenenfalls sind sogar reflektierte XSS-Angriffe oder das Ausführen von Code auf einem Server möglich. Besonders kritisch kann SSRF in einer Cloud-Umgebung sein. Beispielsweise können über Metadaten-URLs wie http://169.254.169.254/latest/user-data unter Umständen direkt Zugangsdaten abgefragt werden [7], wie Abbildung 2 zeigt.

ully_beyond_2.tif_fmt1.jpgAbb. 2: Anfrage mit verändertem URL, SSRF wurde ausgenutzt

Entdeckt werden kann SSRF durch automatisierte Werkzeuge wie den Collaborator [8] des kostenpflichtigen Burp Proxys. Manuell kann es gefunden werden, indem überprüft wird, ob ein Wert eines Requests ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang