In diesem Beitrag im Rahmen unserer QS-Beratungs- und Softwaretestserie werden die Grundlagen der Sicherheit von Webanwendungen behandelt. Verwenden Sie den Namensteil Ihrer E-Mail-Adresse nicht als Anmeldenamen für die App, wenn sich Ihre E-Mail-Adresse überall befindet. Machen Sie keine Selfies mit einem Passwort, das auf einem Whiteboard im Hintergrund geschrieben ist. Und implementieren Sie Captcha nur, wenn Sie es unbedingt müssen!

Es existieren im Kontext von Threat Modeling mehrere Methoden und Tools. Grundsätzlich dreht sich jedoch alles um die folgenden drei Fragestellungen:

1.Wer kann uns angreifen?

2.Welche Ressourcen/Komponenten schützen wir?

3.Wie stellt sich unsere Systeminfrastruktur dar?

Die Definition von Angreiferprofilen kann Sie dabei unterstützen, die Wahrscheinlichkeit von Cyber-Attacken einzuschätzen. Selbstverständlich variieren die Profile in Abhängigkeit von der Branche und der Anwendungsart (Banking, Militär, Corporate Blog). Einige Beispiele sind:

Wettbewerber

Diese können unter anderem ein Interesse daran haben, Daten zu entwenden oder Ihre Nutzererfahrung zu beeinträchtigen – beispielsweise durch das Herabsetzen Ihrer App-Performance.

Bots / Hacker

Teilautomatisierte Bots versuchen, Schwachstellen in Ihrer Anwendung zu identifizieren, um Schadsoftware für das Verbreiten von Spam oder das Mining von Kryptowährungen einzuschleusen.

Anwender

Nutzer Ihrer Anwendungen stoßen (oftmals unbewusst) auf Sicherheitslücken. Sie erhalten beispielsweise unberechtigte Einsicht in Daten, indem Sie Ihre User-ID oder die URL ändern.

Eigene Mitarbeiter

Selbst bei vollstem Vertrauen können Ihre Mitarbeiter unabsichtlich zu einer Sicherheitsbedrohung werden. Klassische Beispiele sind gestohlene Session Cookies, entwendete und fehlerhafte Passwörter oder schlicht Schadsoftware, die auf dem Computer eines Mitarbeiters installiert wurde.

Letztgenannter Punkt ist besonders herausfordernd. „Wir nutzen VPN und lassen ausschließlich vertrauenswürdige Nutzer in das Netz. Wir sind sicher!“ Argumente dieser Art werden ausgehebelt, sobald der Computer eines entsprechenden Anwenders infiziert ist. Zudem kann nur schwer vorhergesehen werden, auf welchem Wege Viren dieser Art ins Unternehmen gelangen. Es könnte ein USB-Stick sein, der ohne Umverpackung geliefert wurde – oder eine gefälschte E-Mail mit dem Betreff „Absatzplanung Folgejahr final“, die den Anschein erweckt, sie würde aus dem Management stammen. Menschen neigen mehrheitlich dazu, diese Art von E-Mails zu öffnen.

Analysieren Sie, welche Ihrer Ressourcen besonders schützenswert sind. Vermögen? Sensible Daten? Möglicherweise muss auch ein Imageschaden durch eine gehackte Website um jeden Preis verhindert werden?

Komponenten

Um alle Angriffsflächen zu identifizieren, erstellen Sie ein Übersichtsdiagramm, welches sämtliche Anwendungskomponenten enthält. Die Hauptseite sowie ihre Backend-API befinden sich hierbei in der Mitte, was zunächst noch wenig aussagt. Wenn das Diagramm dann jedoch wächst, sind Sie möglicherweise überrascht, was sie an seinen Rändern entdecken werden: kaum genutzte, seit Ewigkeiten nicht mehr aktualisierte Legacy-Komponenten – das perfekte Einfallstor für Eindringlinge.

Frontend

Die Webseite ist in aller Regel einer der wichtigsten Zugangspunkte zu Ihrer Web-Anwendung. Sie kann für zahlreiche frontendbezogene Angriffe anfällig sein, wobei XXS eine besondere Rolle spielt. Egal, ob es sich um ein Kontaktformular, ein Suchfeld oder eine URL handelt – überprüfen Sie jede Eingabe, da grundsätzlich jede Komponente, die Parameter akzeptiert, das Ziel eines Angriffs sein kann. Analysieren Sie, wie die clientseitige Anwendungslogik implementiert ist. Überprüfen Sie zudem, welche Nachrichten dem Benutzer angezeigt werden und stellen Sie sicher, dass keine Hinweise in den Quellcode-Kommentaren versteckt sind.

Backend

Jede Webseite muss auf irgendeine Art mit dem Server kommunizieren. Angreifer können dies auch direkt über die API tun. Ist sie ausreichend abgesichert? Welche Endpoints sind öffentlich und müssen diese wirklich offen sein? Wie werden Anfragen authentifiziert? Ist die Autorisierung funktionsfähig? Haben Endbenutzer Zugriff auf Management-Endpoints? Sicher möchten Sie verhindern, dass jemand die Werte der Umgebungsvariablen über den Endpunkt /env des Spring Boot Actuators erlangt.

Datenbank

Sind Sie sicher, dass Ihr Datenbank-Port nicht offen ist? Ist gewährleistet, dass kein GUI-DB-Manager existiert, der unter einer geheimen URL installiert wurde, die nur der Administrator kennt?

 Mobile Endgeräte

Der beliebteste Weg unter Hackern zum Eindringen in Systeme – aber warum?

Oftmals wird das Sicherheitslevel herabgesetzt, um den Anwendungskomfort zu erhöhen (z. B. Captcha nicht erforderlich, Nicht-Beenden von Sessions). Zudem kann die Codebasis mobiler Apps unabhängig von der Hauptanwendung entwickelt werden. Dies kann wiederum dazu führen, dass kritische sicherheitsrelevante Patches vergessen werden. Ist die Backend-API der mobilen Version die gleiche wie die API der Webseite? Wenn nicht, ist dies eine weitere Komponente, die es zu berücksichtigen gilt.

Newsletter

Versenden Sie E-Mails aus Ihrer Anwendung heraus? Beinhalten die E-Mails Links zu Inhalten auf Ihrer Website? Befindet sich der entsprechende Content direkt auf der Seite, oder in einem Bereich, der ausschließlich für Newsletter genutzt wird? Befinden sich die Inhalte auf einem separaten Speicherort, so stellt dies eine weitere gefährdete Komponente dar.

Infrastruktur/Cloud-Komponenten

Insbesondere in Cloud-Umgebungen wird Ihre Anwendung zahlreiche Zusatzkomponenten aufweisen. Hierzu zählen beispielsweise Service Discovery (z. B. Eureka), Management Tools (Spring Boot Admin), Logging und Metriken (Kibana, Grafana) oder andere Hilfsmittel (Redis, RabbitMQ). Sind Sie sicher, dass kein Entwickler/Tester seine Ports geöffnet hat, um von zu Hause aus eine Verbindung herzustellen?

Software von Drittanbietern

Möglicherweise nutzen Sie eine spezielle BPM-Suite, die einige Geschäftsprozesse abdeckt? Oder setzen Sie ein Business-Rule-Management-System ein? Vielleicht verfügen Sie gar über Integrationen mit externen Partnern? Auch dies sind Komponenten, die berücksichtigt werden sollten.

Jedes Schutzkonzept ist individuell. Kein Detail und keine Komponente ist zu klein. Zahlreiche Kleinigkeiten wie RSS-Feeds, Cache-Server oder exotische Plug-ins für die Webseite können sehr schnell in Vergessenheit geraten.

Nachdem sämtliche Softwarekomponenten abgebildet sind, gilt es, Transparenz hinsichtlich der Infrastruktur zu schaffen. Wie viele Umgebungen existieren? Welche Server sind im Einsatz? Wie sind diese miteinander vernetzt? Wie stellt sich ihre Internetverbindung dar?

Schützen Sie Ihre Entwicklungs- und Testumgebungen

Aus Sicht des Angreifers sind die Entwicklungs- und Testumgebungen am interessantesten. Der Grund: In der Regel ist die Sicherheitskonfiguration hier „großzügiger“ als in der Produktion. Der Komfort des Programmierers hat oftmals höhere Priorität als die Sicherheit des Systems.

Hat sich ein Angreifer Zugang zur Entwicklungsumgebung verschafft, kann er zahlreiche Aktivitäten durchführen:

• Erfolgreichen Angriff auf den Produktionsserver vorbereiten
• Datendiebstahl (Sicherheitslücken, die durch das Kopieren unveränderter Produktionsdaten in die Entwicklungsumgebung entstehen, sind keine Seltenheit.)
• Passwörter entwenden (einige davon können in der Produktion gültig sein)
• Installieren von Schadsoftware auf Entwicklungsservern
• Detaillierte Debugging-Logs analysieren

Der externe Zugriff auf Quellcode-Repositories sollte ebenfalls eingeschränkt werden. Angreifer könnten sonst die Passwörter aus Ihren Konfigurationsdateien auslesen.

Wie können Angreifer Ihre Entwicklungsumgebung auffinden?

DNS-Transfer

Zunächst wird der Versuch unternommen, Ihre Domain zu analysieren und DNS-Informationen zu übertragen. Ein Werkzeug, das dies ermöglicht, ist das Host-Programm (DNS-Lookup-Utility). Wenn Sie den Abfragetyp als NS definieren, wird der Name-Server-Eintrag für die angegebene Domäne angezeigt:

$ host -t NS example.com

example.com name server b.iana-servers.net.

example.com name server a.iana-servers.net.

Dann wird der Host im List Mode versuchen, den Zonentransfer durchzuführen (möglich durch Option -I).

$ host -l example.com b.iana-servers.net

Wenn die Übertragung erfolgreich ist, sieht der Angreifer alle registrierten Subdomains, wie dev.example.com, test.example.com, qa.example.com und so weiter. Zudem werden die jeweiligen IP-Adressen sichtbar. Um dies zu verhindern, überprüfen Sie Ihre DNS-Konfiguration und stellen Sie sicher, dass Zonentransfers gesperrt sind.

DNS Brute Forcing

Wenn ein einfacher DNS-Transfer fehlschlägt, kann der Angreifer versuchen, die Subdomains mithilfe des sogenannten DNS Brute Forcings zu ermitteln. Eine Software, die hierzu in der Lage wäre, ist dnsenum. Wenn ein Dictionary mit einer Liste von Domänenpräfixen, die Zieldomäne und der DNS-Server bereitgestellt werden, werden alle vorhandenen Subdomänen ausgegeben. Es existieren öffentliche Dictionaries für dnsenum, die zahlreiche wahrscheinliche Ansätze enthalten.

Nachdem der Angreifer die IP-Adressen Ihrer Server erhalten hat, wird er im Normalfall Ihre Ports scannen, nach offenen Ports suchen und weitere Schritte planen. Es hat sich bewährt, alle Testumgebungen in privaten Netzwerken vor der Öffentlichkeit zu verbergen und den Remote-Zugriff für Mitarbeiter ausschließlich über VPN-Netzwerke zu ermöglichen.

Zuletzt können Sie in Betracht ziehen, HTTPS-Verbindungen nicht nur in der Produktion, sondern auch in den Testumgebungen zu nutzen. Die Zertifikate können selbst signiert werden, da dies hier keine Rolle spielt. Wichtig ist in jedem Fall, dass weder Ihre Mitarbeiter noch die auf ihren Rechnern installierten Viren in der Lage sind, den HTTP-Traffic im VPN zu analysieren.

Dieser Artikel ist als eine Art Sicherheitsbriefing für Web-Anwendungen gedacht. Er richtet sich gleichermaßen an Entwickler und Betriebswirtschaftler. Es wurden zahlreiche Themen kurz angeschnitten, die selbstverständlich im Detail gegoogelt werden können. Festzuhalten bleibt: In unserer Zeit ist es extrem wichtig, zumindest die grundlegenden Sicherheitsvorkehrungen zu kennen. Zudem ist eine Checkliste hilfreich, die sämtliche Punkte beinhaltet, die aus Security-Sicht überprüft werden müssen. Im nächsten Beitrag befassen wir uns mit verschiedenen Angriffstechniken.